For EGit change I2c41d86b8b74c2a334433de1bbfed5b36af872bf,
ContainerTreeIterator also needs to create entries for File objects in
case of filtered resources. Instead of reimplementing FileEntry there,
make the constructor public so that it can be reused.
Also allow to pass a WorkingTreeIterator instead of a FileTreeIterator
in FileTreeIterator's constructor, which is enough and allows to pass
other subclasses.
Bug: 358901
Change-Id: Ie0f9c9434ef7d73a8d73d4fe46db4147ded1d267
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Also extend documentation and add examples.
Bug: 395599
Change-Id: Id1ddbc9da787472f82e58834092bc073224b262b
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
StartGenerator now processes .git/shallow to have the
RevWalk stop for shallow commits.
See RevWalkShallowTest for tests.
Bug: 394543
CQ: 6908
Change-Id: Ia5af1dab3fe9c7888f44eeecab1e1bcf2e8e48fe
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The 'edit' command allows you to change arbitrary commit
content and the message of any commit in the repository.
Bug: 394577
Change-Id: I43a44782cdb10b29f13784fa75ab37fe5d4da01b
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
'reword' command is used to change commit message of any
commit in git history.
Bug: 394575
Change-Id: Ic974e76dfd923fd6f0cb8f07d1a6fbecd9abbf31
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Otherwise loading javax.net.ssl.TrustManager fails if
osgi.compatibility.bootdelegation=false which became the Equinox default
since bug 344850 was fixed.
Bug: 392056
Change-Id: I464871723649095942dbf77da93890ac8ec39075
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
This adds the possibility to:
* retrieve untracked directories from the status
* instruct the CleanCommand to clean those directories.
* retrieve ignored paths from the status
* instruct the CleanCommand to leave those ignored paths alone
Bug: 338717
Change-Id: Ibed0459005a5e306c010b9932f5b5fd107fb5448
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The checkoutPaths body is split into two implementations, depending on
whether we are checking out the index or a branch. This improves
readability, as in the index case we now also need to have access to
DirCacheIterator.
Bug: 390147
Change-Id: I99fd599b25b2ace9bdd84535a56565286a3cb7f1
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Our rule to enforce javodocs for public members gives us a problem
because there are some patterns where javadoc make little sense so we
make the comments as small as possible, which our formatting rules do
not like, so disable it for those source files.
Change-Id: I6e3edb1e650ed45428b89cf41e6151b6536bca8a
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Note the the settings are slightly less restrictive for test bundles.
-Also cleanup a couple of malformed javadocs
-Update compiler warnings/errors to include default values from Juno
-We now flag diagnosed null dereference as error. We didn't do that
earlier because of some false positives.
Change-Id: I58386d63164e65d3d8d1998da3390d99bdc7381a
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
This behavior was defined in the Javadoc of PathEdit, but not actually
implemented.
It's necessary when one wants to use a PathEdit to check out a specific
stage in apply.
Bug: 390147
Change-Id: Iaed5cf60c554fc17e6c4d188caf4f0231da920d0
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Change-Id: I458167739210214fa54c4b3d62fac5abc82f96f7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The test checks if an error is thrown when trying to create the same tag
for the second time.
Change-Id: I4ed2f6c997587f0ea23bd26a32fb64a2d48a980e
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
With bug 391855, PathEdit will be changed to apply an edit for each
stage. With that, CommitCommand would no longer work correctly when
committing an unmerged path.
This changes it to use a DirCacheBuilder which allows us to correctly
replace the entries for the three stages with one, which is not possible
with PathEdit.
Bug: 391859
Change-Id: I6dc180aec7e2cbf8d1e91f50482c95bc420f79de
The DfsPackFile will fire any static repository listeners on the event
just before the PackIndex is loaded.
Change-Id: Ie51098106bd5a1a32feae7d2dd068abf02b030ee
With bug 391855, DirCacheEditor's PathEdit will be applied for each
stage. For an unmerged path, this would result in 3 equal entries for
the same path.
By using a DirCacheBuilder, the code is simpler and does not have the
above problem with unmerged paths.
Bug: 391860
Change-Id: I785deeaeb8474f8c7a7fbc9ef00d3131fac87e41
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The previous implementation used a PathEdit, which does not reset the
stage of the entry.
Bug: 391860
Change-Id: If26d3a35abfee85424ad69de724f06a28b6e9efb
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
These appear as descriptions in the index, see here (currently empty):
http://download.eclipse.org/jgit/docs/latest/apidocs/
Change-Id: If7996deef30ae688bade8b3ad6b19547ca3d8b50
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
The API was changed to not allow null values anymore with
I0ac994ae8e47789d38f7c6e6db55d482f0f1bac3, leading to an IAE.
Bug: 393054
Change-Id: If33560ae976b46a02ff75b2e4ec05c13a8ad2d41
For streams that should not be closed, i.e. don't own an underlying
stream, and in-memory streams that do not need to be closed we just
suppress the warning. This mostly apply to test cases. GC is enough.
For streams with external resources (i.e. files) we add the necessary
call to close().
Change-Id: I4d883ba2e7d07f199fe57ccb3459ece00441a570
If a client attempts to create a branch that already exists on the
remote side, tell them "already exists" rather than repeat lots of
information about the reference. Previously the error looked like:
! [remote rejected] tags/1.3.1 -> 1.3.1 (Ref Ref[refs/tags/1.3.1=e3857ee05...] already exists)
Now it will simply say:
! [remote rejected] tags/1.3.1 -> 1.3.1 (already exists)
Change-Id: I96fc67ca8b650052de6e662449a3c5bc8bbc010b
In code review we often see uses of JGitInternalException where a high
level GitAPIException would be more appropriate. Hopefully the word
low-level in the constructor comment will lead to fewer such cases.
Change-Id: Id5ec7897535f6c5c5f0bd153fe0ff15c65083474
toExternalString, equals and hashCode don't expect them to be null, so
explicitly disallow it in the constructor.
Also fix the documentation of setAuthor and setCommitter in
CommitCommand when specifying name and email as separate arguments.
Bug: 352984
Change-Id: I0ac994ae8e47789d38f7c6e6db55d482f0f1bac3
In Iff768422c the offset used for the content id was fixed to use the
offset that applied to the dircache iterator. Unfortunately the index
for the dircache content id offset stuck for entries that were not in
the index. Few caller probably cared about that, unless it actually
caused an ArrayIndexOutOfBoundsException.
Change-Id: Ic9f0e77c8ea3a0770d88565e94392e76853e3006
Change-Id: I07aca821010daca75a66506b9ca738bc8c262abb
Signed-off-by: Markus Keller <markus_keller@ch.ibm.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Makes it much easier to debug the results of
OperationResult#getTrackingRefUpdates (which otherwise requires digging
into a TreeMap structure).
Change-Id: I90da5385ee47c441404728f252eb3a100c48ee1c
Valid refs are defined by git-check-ref-format(1). In addition
we will not try to perform a lookup of an invalid ref name in
Repository.resolve().
Reported by R Shapiro in the Eclipse JGit Forum.
Change-Id: I0b098eec9ecb98a9ce16b1cfb476729aaf2fb190
Without this check, the checkout was done but the result was a "both
deleted" status when inspecting it with C Git.
Found this while working on bug 390147.
Change-Id: Ic3693f2c651827239e838bf7f37da842a7ae9707
Clarify expiration of objects with the modification time exactly at the
given time instant.
Change-Id: I2000aec89c8d6a95700380b0a32275d2d658f67e
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
This prevents a lot of unnecessary warnings about disouraged usage of
the org.eclipse.jgit.internal package within JGit itself.
Change-Id: Ia6683902809425fd7245e7d5d344c2ff8f317ebb
* stable-2.1:
Prepare for 2.1 maintenance changes
JGit v2.1.0.201209190230-r
Introduce "never" as parseable date
Introduce ParseExceptions for GitDateParser
Support config param "gc.pruneexpire"
Change-Id: If149d7f968a3425d9425f6ba9ce135a8341776a7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
resolve("foo~X") where X is greater than the distance from foo to the
root should return null, but 2a2362fb introduced a bug causing it to
either return resolve("foo") or NPE. Add a test for the correct
behavior.
Also add an analogous test for foo^X where X is greater than the
number of parents (which was not broken by that commit).
Change-Id: Ic580081ece57c8c2df29b652897b425ecb34e11f
For configuration parameter like "gc.pruneexpire" we need to understand
the value "never". Never is handled as a date so far into the future
that it will never happen. The actual value currently used is the
constant GitDateParser.NEVER.
Change-Id: I7744eaee9bf5026da517151c212c88325c348d6c
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Instead of just returning null when something was not parseable we
should throw a real ParseException. This allows us to distinguish
between specifications which are unparseable and those which represent
no date (e.g. "never")
Change-Id: Ib3c1aa64b65ed0e0270791a365f2fa72ab78a3f4
Make GC honor the config parameter gc.pruneexpire. If the parameter is
not set then the default is "2.weeks.ago"
Change-Id: I0ae0ca85993cafb4bc75ba80504da18544894ec3
Change-Id: Id5b578f7040c6c896ab9386a6b5ed62b0f495ed5
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The underlying problem is that System.out is a PrintWriter and
as such it does not throw exceptions on error, but rather just
sets a flag and continues.
This changes replaces the use of System.out with a PrintWriter-like
writer that does not catch error, but instead throw them to the
caller.
Bug: 366243
Change-Id: I44405edc4416e943b87f09a0f6ed041c6c51b046
Change-Id: I98fc9720106bcd873b330090bafde276508f8a40
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ResolveMerger throws a MissingObjectException when it encounters
a submodule conflict while merging. The reason is that it treats
the submodule link as a blob and tries to read its contents.
We solve the issue by detecting before content merge whether the
path to be merged is a submodule link, and skip the content
merge if it is.
Bug: 389238
Change-Id: I9a58dfc7716b28a21f5c04cf3a865091ae8dfe7e
Signed-off-by: Tommi Siivola <tommi.siivola@eficode.com>
The value of -1 is the default value used by the underlying http
transports provided by the jre. On some versions an attempt to
set the timeout explicitly to -1 triggers a check condition,
disallowing negative numbers.
Bug: 389003
Change-Id: I74a22f8edc6c8e15843ad07c96a137739d9dcad1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
None of these should have been exposed to base classes. The majority
of them are private implementation details that are not required by a
subclass in order to interact with the base protocol definition. The
few that are needed should be visible as accessor methods, so the
internals can be modified without breaking the public JGit API.
Change-Id: I874179105c9c37703307facbbf99387c52bf772c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This flag was added to provide an unsafe operation on the local
repository because the storage.dht code was too damn slow to provide
proper safe Git behavior all of the time. Now that stoarge.dht has
been removed from the repository, also delete this unsafe flag to
prevent applications from misusing the JGit library and permitting
users to potentially damage their local repository with bad data
received from an untrusted peer.
Change-Id: Ib1861c48bb74836731e7b7d57b635dd654b0dc66
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When a file is not in the index and neither contents nor mode differ
between "head" and "merge", the index state should be kept. If they
differ, a checkout conflict should occur. This is described in Git's
git-read-tree.txt.
JGit used to replace the index state with "merge" in both of the above
cases.
A confusing effect of this was that when one removed a file and then did
a rebase, the file silently reappeared again.
The changes to dir/file conflict handling are a consequence of this
change, as the index handling change made tests in DirCacheCheckoutTest
break. I compared these cases to C Git and the new behavior there also
matches what C Git does.
Bug: 387390
Change-Id: I5beb781f12172a68f98c67d4c8029eb51ceae62d
Signed-off-by: Robin Stocker <robin@nibor.org>
The transformation is the same as AutoCRLFOutputStream does, but
the direction is reversed. The tests are reused, but the implementation
derives somewhat from the EolCanonicalizingInputStream.
This stream will be used to compare blobs with LF line endings with
worktree data that has CRLF line endings.
Bug: 387501
Change-Id: I80d96e453e7f780dd464a89778de124cf35384e1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The statistics for a repo now expose how many bytes are used in the
filesystem to store all loose/packed objects. The number of packed/loose
refs are also exposed.
Change-Id: I335a4c7630a2629a86f13a2a5cd99f79a2c2afa4
In order to parse user specified strings containing date and time info
a thread-safe parser is implemented. This is needed for example to
interpret configuration parameters (e.g. gc.pruneexpire where need to
parse strings like "2 weeks ago"). The parser is thread-safe by caching
SimpleDateFormat instances in a ThreadLocal cache.
Native git has a parser called approxidate which is able to interpret a
huge number of formats ("1 year ago", "tea time", ...). Ideally JGit
should be able to parse the same strings as native git but for now this
parser understands the following subset:
"now"
"yesterday"
"(x) years|months|weeks|days|hours|minutes|seconds ago"
"yyyy-MM-dd HH:mm:ss Z" (ISO)
"EEE, dd MMM yyyy HH:mm:ss Z" (RFC)
"yyyy-MM-dd"
"yyyy.MM.dd"
"MM/dd/yyyy"
"dd.MM.yyyy"
"EEE MMM dd HH:mm:ss yyyy Z" (DEFAULT)
"EEE MMM dd HH:mm:ss yyyy" (LOCAL)
Change-Id: Iccb66dadb60da13104e73140e53d5e2de068369c
EGit should be able to continue a rebase started by C Git.
Change-Id: I63058026295fec34157b5687ae87ae9cb0c27c86
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Java has no option but to use precomposed Unicode, so we should
state that when creating a new repository. Not that Java will use
precomposed unicode regardless of this setting, but this reduces
the risk of incompatibility with C Git.
Change-Id: I3779b75f76d2e2061c836cbc9b4b7c2ae0cf18f4
* changes:
Support [<ref>]@{upstream} revision syntax
Support parsing previous checkout as a revision expresion.
Allow a @ without branch in revision syntax
JGit was not able to lookup refs which had the name of files which exist
in the .git folder. When JGit was looking up a ref named X it has a
fixed set of directories where it searched for files named X
(ignore packed refs for now). First directory to search for is .git. In
case of the ref named 'config' it searched there for this file, found it
(it's the .git/config file with the repo configuration in it), parsed
it, found it is an invalid ref and stopped searching. It never looked
for a file .git/refs/heads/config.
I changed JGit in a way that when it finds a file in GIT_DIR which
corresponds to a ref name and if this file doesn't contain a valid ref
then it will ignore the InvalidObjectIdException and continue searching.
Change-Id: Ic26a329fb1624a5b2b2494c78bac4bd76817c100
Bug: 381574
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
The method uses some heuristics to obtain much better performance
than isMergeBase.
Since I wrote the relevant code in the method I approve the license
change from EPL to EDL implied by the move.
Change-Id: Ic4a7584811a2b0bf24e4f6b3eab2a7c022eabee8
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
EGit wasn't able to decorate local branches tracking another local
branch with number of commits the checked out local branch differs from
the other local branch it's tracking.
Bug: 376970
Change-Id: I74e932d5eacd74dbf6b0dffcfc65ba3222a8250e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
On conflicts in rebase or cherry-pick, the conflict markers were like
this:
<<<<<<< OURS
a
=======
b
>>>>>>> THEIRS
This is technically correct, but it could be better.
It's especially confusing during a rebase, where the meaning of
OURS/THEIRS is not obvious. The intuition is that "ours" is the commits
that "I" did before the rebase, but it's the other way around because of
the way rebase works. See various bug reports and stackoverflow
discussions.
With this change, in the case of a cherry-pick while on master, the
markers will be like this:
<<<<<<< master
a
=======
b
>>>>>>> bad1dea Message of the commit I'm cherry-picking
In the case of a "git rebase master":
<<<<<<< Upstream, based on master
a
=======
b
>>>>>>> b161dea Message of a commit I'm rebasing
It's not "master" because that would only be correct for the first
cherry-pick during a rebase, after that, it's master + already
cherry-picked commits.
And in the case of a "git pull --rebase":
<<<<<<< Upstream, based on branch 'master' of git@example.org:repo
a
=======
b
>>>>>>> b161dea Message of a commit I'm rebasing
Bug: 336819
Change-Id: I1333a8dd170bb0077f491962013485efb6f2a926
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The file location of the constructor for BlameGenerator
did not specify where the path should be relative from.
Fix BlameGenerator comments based on suggestions by Robin Stocker.
Change-Id: I3d79db2d2ba4961835fe664ae6178e0bfc97b910
In DFS, everything is stored in a pack but only objects in a pack with
source GC or UNREACHABLE_GARBAGE have had delta compression attempted.
Expose the PackSource setter and getter on DfsPackDescription in order
to implement wasDeltaAttempted.
Change-Id: Ie949f321147ad870f1c3f23b552343bbbda32152
If an object is in a pack file already, delta compression will not
attempt to re-compress it. This assumes that the previous
packing already performed the optimal compression attempt, however,
the subclasses of StoredObjectRepresentation may use other heuristics
to determine if the stored format is optimal.
Change-Id: I403de522f4b0dd2667d54f6faed621f392c07786
This change makes CheckoutCommand pass the list of modified files
through the OK result, enabling outside world to react in a smaller
scope (for example refresh only resources containing the modified
files).
Change-Id: I53c50ee09bc0d3ff501bdc25196e52e739c3f1f9
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Change-Id: I03f59d07bcc3338ef8d392cbd940799186ca03bd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Since git doesn't keep track of empty directories, they should be
created first. Test case included demonstrates that using
StashApplyCommand(). Bugfix is applied to the DirCacheCheckout class,
because StashApplyCommand() uses it internally to apply a stash.
Change-Id: Iac259229ef919f9e92e7e51a671d877172bb88a8
Signed-off-by: Jevgeni Zelenkov <jevgeni.zelenkov@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit allows to create commits which have duplicate parents: e.g. a
commit X has first parent Y and second parent Y. Such commits are not
handled correctly by PlotCommit leading to wrong display of the history
in EGit. In such cases there is a never ending passing line drawn beside
all commits younger than the commit with duplicate parents. This commit
fixes this by explicitly checking for duplicate parents.
In a different commit we should fix JGit not to create commits with
duplicate parents. I think native git also doesn't allow such commits,
although history display in native git (gitk, git log --graph) is not
damaged by such commits.
Change-Id: Ie3019ef613a507023958bea27b1badc3b8950279
Implements a garbage collector for FileRepositories. Main ideas are
copied from the garbage collector for DFS based repos
(DfsGarbageCollector). Added functionalities are
- pruning loose objects
- handling of the index
- packing refs
- handling of reflogs (objects referenced from reflog will not be
pruned/)
These are features of a GC which are not handled in this change and
which should come with subsequent changes:
- unpacking packed objects into loose objects (to support that pruning
packed objects doesn't delete them until they are older than two weeks)
- expiration of reflogs
- support for configuration parameters (e.g. gc.pruneExpire)
Change-Id: I14ea5cb7e0fd1b5c50b994fd77f4e05bfbb9d911
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Expose class DfsReader and method DfsPackFile.hasObject() as public.
Applications may want to be able to inquire about some details of
the storage of a repository. Make this possible by exposing some
simple accessor methods.
Expose method DfsObjDatabase.clearCache() as protected, allowing
implementing subclasses to dump the cache if necessary, and force
it to reload on a future request.
Change-Id: Ic592c82d45ace9f2fa5f8d7e4bacfdce96dea969
A configured remote url like "../repo" works with C Git.
In JGit, it only worked if Java's current working directory happened to
be the local repository working directory.
Change-Id: I33ba3f81b37d03cf17ca7ae25a90774a27e7e02b
Signed-off-by: Robin Stocker <robin@nibor.org>
Currently, after a merge/cherry-pick/rebase, all index entries are
smudged as the ResolveMerger never sets entry lengths and/or
modification times. This change teaches it to re-set them at least for
things it did not touch. The other entries are then repaired when the
index is persisted, or entries are checked out.
The first attempt to get this in was commit
3ea694c252 which has been reverted.
Since then some fixes to ResolveMerger and a few more tests have
been added which check situations where the index is not matching
HEAD before we merge.
Change-Id: I648fda30846615b3bf688c34274c6cf4bc857832
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Also-by: Markus Duft <markus.duft@salomon.at>
Repository.resolve can only return an ObjectId and will
continue to do so, but another method, simplify(), will
be able to return a branch name for some cases.
Previous checkouts can be specified as @{-n}, where n is an
integer speifying the n:th previous branch. The result
is the branch name, unless the checkout was a detached head,
in which case the object id is returned. Since the result
is a branch it may be followed by a references to the reflog,
such as @{-1}@{1} if necessary.
A simple expression like "master" is resolved to master in
simplify, but anything starting with refs gets resolved to
its object id, even if it is a branch.
A symbolic ref is resolved to its leaf ref, e.g. "HEAD" might
be resolved to "master".
Change-Id: Ifb815a1247ba2a3e2d9c46249c09be9d47f2b693
Currently, after a merge/cherry-pick/rebase, all index entries are
smudged as the ResolveMerger never sets entry lengths and/or
modification times. This change teaches it to re-set them at least for
things it did not touch. The other entries are then repaired when the
index is persisted, or entries are checked out.
Change-Id: I0944f2017483d32043d0d09409b13055b5609a4b
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
No branch before @ is interpreted as the currently checked out branch.
For detached heads it would be HEAD, but normally it is the branch
that HEAD refers to.
Change-Id: I051a1724fa390b8212e8986ba832b1347a20371e
Otherwise applying will fail with a FileNotFoundException, because
File.createNewFile() fails with missing parents.
Contains change & according test.
Change-Id: I970522b549b8bb260ca6720da11f12c57ee8a492
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
An example where this is necessary is when a whole directory was deleted
and checkout is used to restore a file which was in that directory.
Bug: 372133
Change-Id: I1d45e0a5d2525fe1fdfbf08c9c5c166dd909e9fd
Signed-off-by: Robin Stocker <robin@nibor.org>
* stable-2.0:
Improve performance of persisting an index by magnitudes
Change-Id: I880f4d0be81c263b598ee24e8373c6f8cb781c51
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When updating smudged entries use a pathfilter to iterate only over
working tree files which have an associated smudged index entry.
Commit dac66672df introduced that we
check and update smudged entries while persisting a dircache. Before
that commit adding a file to git caused file i/o for the index file,
the object database (to store new content) and all files we wanted to
add (to read new content). After that commit we have additionally file
i/o for every file in the working tree (even ignored files).
Especially on windows iterating over the working tree can be very
time consuming. This decreased the performance of persisting a dircache
dramatically (I measured factors 4 to 10 while adding a file to linux
kernel repo). One could easily see this effect when dragging&dropping
modified files in a linux kernel repo in the egit staging view.
Change-Id: I568dec77635013cf6bb46f652d3f2b89de041c82
Signed-off-by: Kevin Sawicki <kevin@github.com>
I have unfortunately introduced a few bugs in the native Git client
over the years. 1.7.5 is unable to send chunked requests correctly,
resulting in corrupt data at the server. Ban this client whenever
it uses chunked encoding with an error message.
Prior to some more recent versions, git push over HTTP failed to
report status information and error messages due to a race within
the client and its helper process. Check for these bad versions and
send errors as messages before the status report, enabling users
to see the failures on their terminal.
Change-Id: Ic62d6591cbd851d21dbb3e9b023d655eaecb0624
It was easy to create multiple packs with exactly the same name and
same DfsRepositoryDescription in a test, which can poison the
DfsBlockCache. The javadoc for DfsObjDatabase.newPack() explicitly
says pack names should be unique within an entire DFS, so do this by
making the packId AtomicInteger static.
Arguably, test writers shouldn't be doing things like putting
'new DfsRepositoryDescription("test")' in a setUp() method, but that's
a natural thing to do, and we don't document this restriction
anywhere.
Change-Id: I9477413ab3950d83b7d17e173fbc0a3e064896e3
The PackParser EOF check is incompatible with the expect data after
pack footer flag, so turn off the EOF check if the expecting data
flag is true.
Change-Id: I697ebd9e1d1eed765d00aecaef955cf978cfd0b9
This was broken in fe1f1b8f8a, which
preferred the index over the working tree when both were present.
Change-Id: I97dcf9a088adcbd0187fa7eec9ef34445ce3a981
Signed-off-by: Kevin Sawicki <kevin@github.com>
When starting a rebase with C Git, there may be empty lines in the
git-rebase-todo file. Before this change, JGit would fail to parse the
file with e.g. the following exception:
JGitInternalException: Unknown or unsupported command "
#", only "pick" is allowed.
This happened when there was an empty line just before the comments,
because the nextSpace would be the one from the comment. Now the empty
lines are ignored by checking for nextSpace < ptr outside of the loop.
Change-Id: I94ad299f367c846e7729c74f49c6b8f93f75ae81
Signed-off-by: Robin Stocker <robin@nibor.org>
Before, the paths to delete were stored in a HashMap, which doesn't have
a particular order. So when e.g. both the file "a/b" and the directory
"a" were to be deleted, it would sometimes try to delete "a" first. This
resulted in a failed path because File#delete() fails when a directory
isn't empty.
With this change, an ArrayList is used for storing the paths to delete.
The list contains the paths in a top-down order, as defined by the order
of processEntry. When the files are deleted, the list is iterated in
reverse, ensuring that all files of a directory are deleted before the
directory itself.
Bug: 354099
Change-Id: I6b2ce96b3932ca84ecdfbeab457ce823c95433fb
Signed-off-by: Robin Stocker <robin@nibor.org>
ResolveMerger#mergeImpl() was only returning false (= failed) when there
were unmerged paths. In the case when there were only failing paths, it
returned true.
Because MergeCommand looks at the return value for determining if the
merge failed, it would fall into the successful case there, where it
should instead return a MergeResult with MergeStatus.FAILED.
This change adds a test case for this and makes the ResolveMerger return
false when there are failing paths.
This was discovered while working on fixing bug 354099 and is needed for
its test case.
Bug: 354099
Change-Id: I499f518f6289ef93e017db924b2aa857f2154707
Signed-off-by: Robin Stocker <robin@nibor.org>
EGit needs this to be able to revert unsaved changes.
Change-Id: I50cc8056aaff47fef6080970866962e3eb634e29
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Whenever a call to JGit returns a Repository the caller should make sure
to call close() on it if he doesn't need it anymore. Since instances of
Repository contain e.g. open FileOutputStreams (for pack files)
forgetting to close the repository can lead to resource leaks.
This was the reason why dozens of the JUnit tests failed on Windows
with "Can't delete file ...." errors.
In LocalDiskRepositoryTestCase.tearDown() we tried to delete the
repositories we used during tests which failed because we had open
FileOutputStreams.
Not only the obvious cases during Clone or Init operations returned
Repositories, but also the new SubModule API created repository
instances. In some places we even forgot to close submodule repositories
in our internal coding.
To see the effects of this fix run the JGit JUnit tests under Windows.
On other platforms it's harder to see because either the leaking
resources don't lead to failing JUnit tests (on Unix you can delete
files with open FileOutputStreams) or the java gc runs differently and
cleans up the resources earlier.
Change-Id: I6d4f637b0d4af20ff4d501db091548696373a58a
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When receiving a pack, data buffered after the pack can restored
to the InputStream if the stream supports mark and reset.
Change-Id: If04915c32c91be28db8df7e8491ed3e9fe0e1608
Split Service into MultiRequestService (fetch, push) and
LongPollService (upcoming publish-subscribe).
Change-Id: Ice373d3dee63c395490d2707473ccf20a022e5cf
It is not always appropriate to use the .gitmodules file from the
working tree, for example if reading the modules at a specific commit.
And sometimes it is impossible, as in a bare repository.
When using the static factory methods, automatically set up the
appropriate root tree so lazy loading of the config file reads from
the appropriate place. Leave the current behavior of looking in the
working tree as a fallback for the case where walking the index.
Change-Id: I71b7ed3ba16c80b0adb8c5fd85b5c37fd4aef8eb
Robin Stocker