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>
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
We need a way to release the underlying TreeWalk. Also, use this
method to release walks from the static factory methods on error or
when submodules are not found.
Change-Id: I6bedc2db78bcd577aef2cfe6715bb981a26dcfd7
Relax the read() method to not block until exactly "len" bytes have
been read. Instead, return when one or more bytes have been read, up
to "len", so UnionInputStream more closely resembles InputStream's
read() method.
Change-Id: I3f632be8eb85a4a0baf27c9f067c8d817162de2b
The base class supplies an ObjectInserter to its implementations
by way of the getObjectInserter method. Tracking a second inserter
instance doesn't match with the expected behavior.
Change-Id: I78996bd06ef9028c8aa2e4e192ff647c43da847d
Filter supports wrapping another ObjectInserter. By default all
methods are delegated to the wrapped inserter. Implementors may
override methods selectively for altered behavior.
The instance that is wrapped may be determined dynamically by code,
supporting lazy allocation of the delegate, or other patterns like
object pooling.
Change-Id: I7b2613d09e73f94e675bad33afbb693f6a7f3df6
Gerrit Code Review needs to control which inserter is used by a
Merger. Allow the application to set the inserter before calling
merge, giving callers more direct control over how objects will
be created.
Change-Id: I3c527a493db4659e95289ff3077cffb9e32336cf
Let a Transport instance be opened with only a URI, for use in the
upcoming publish-subscribe feature.
Change-Id: I391c60c10d034b5c1c0ef19b1f24a9ba76b17bb5
* stable-2.0:
Prepare post v2.0.0.201206130900-r builds
JGit v2.0.0.201206130900-r
Add org.eclipse.jgit.pgm.feature to enable consumption via p2
Do not set core.autocrlf when creating repo
Change-Id: Ifdd71a6bc14d9c79f4433ebc3b53bf0042a4d4c8
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
core.autorlf defaults to false, but can be set in the user or
"system" config files. Note that EGit/JGit may not know
where the "system" config file is located.
Also fix pgm's ConfigTest which depends on default repository
configuration.
Bug: 382067
Change-Id: I2c698a76e30d968e7f351b4f5a2195f0b124f62f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
By Robin Rosenberg (6) and others
via Gerrit Code Review @ Eclipse.org (2) and Matthias Sohn (1)
* stable-2.0:
Prepare next 2.0.0-SNAPSHOT builds
JGit v2.0.0.201206060730-rc3
Remove Jetty p2 repository from Maven build
Get rid of warnings about empty statments
Removed unused parameters from private methods
cleanup: Remove unused declarations
Make FS OS X detection work for OpenJDK
Use working tree iterator to compare file modes
Further cleanup of exceptions in Git API
Update build to use Tycho 0.15.0
Throw formal CheckoutConflictException on hard reset
Configure maven-source-plugin execution in parent POM
Support gitdir: refs in BaseRepositoryBuilder.findGitDir
Relax RevisionSyntaxException to an IllegalArgumentException
Change-Id: I05727693e0c9e762d4fc220ceadcd5a5bfb11d0d
This updates the timestamp of files that are not touched during
checkout. Otherwise the timestamp will always be zero, causing the
IndexDiffFilter to always calculate the checksum of file contents.
Change-Id: I18047f5725f22811bb4194ca1d3a3cac56074183
In HtttpAuthMethod there were comments, but not in a style
that Eclipse recognizes.
Change-Id: I64f55b27143f8badcefbb419d3951f2a26b87d5f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* changes:
Use BatchRefUpdate for tracking refs in FetchProcess
Batch reference updates together for storage
Expose ReceiveCommand.updateType to check for UPDATE_NONFASTFORWARD
Reject non-fast-forwards earlier in BaseReceivePack
Add isModeDifferent method to WorkingTreeIterator
that compares mode with consideration of the
core.filemode setting in the config.
Bug: 379004
Change-Id: I07335300d787a69c3d1608242238991d5b5214ac
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
- Translate internal exceptions to corresponding API exception
- Do not catch GitAPI exceptions internally to an internal
exception. Just pass them to caller
- Mention thrown exceptions in javadoc
Change-Id: I9044cf86d2b0bcc8b63b7cc016e1bf0055a62053
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This will allow calling classes to have access to the
conflicts that occurred during the attempted checkout.
Even though setFailOnConflict(false) is called on the
DirCacheCheckout a CheckoutConflictException can still
be thrown if cleanup fails.
Change-Id: Iea7ad3176a1b0e8606a643de8945e276718eb3ce
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This allows findGitDir to be used for repositories containing
a .git file with a gitdir: ref to the repository's directory
such as submodule repositories that point to a folder under the
parent repository's .git/modules folder
Change-Id: I2f1ec7215a2208aa90511c065cadc7e816522f62
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
PackWriter supports excluding objects from being written to the pack.
You may specify a PackIndex which lists all those objects which should
not go into the new pack. This feature was broken because not all
commits have been checked whether they should be excluded or not. For
other object types the exclude algorithm worked. This commit adds the
missing check.
Change-Id: Id0047098393641ccba784c58b8325175c22fcece
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This change is required by egit's lazy loading of the body in the
history view when the walk is started with setRetainBody(false).
Change-Id: I9291ba8c34c8744bc009b1bd302ed28bfa4e9476
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Write the old object id from the RefUpdate to the
ORIG_HEAD file after the update completes.
Add two new convenience methods to Repository to read
and write the ORIG_HEAD reference similar to the methods
for reading/writing CHERRY_PICK_HEAD and MERGE_HEAD.
Bug: 375525
Change-Id: I120b3b2cd3b1ddae88fce435285bae15cbf96f5e
All commands should throw a GitAPIException so new exceptions can be
added without breaking the builds of old code, i.e. anyone that calls
a Git API should catch GitAPIException and not just the currently known
exceptions.
Now the only checked exceptions on Git API calls are GitException and
subclasses of it. New checked exceptions that are subclasses of
GitException may be added without breaking the API.
Javadoc for GitAPIException is declared on GitCommand and
inherited to subclasses. JGitInternalException is not explicitly
documented anymore.
Unfortunately this change itself breaks the API. The intention is
that it shall be possible to add new checked subclasses of
GitAPIException without breaking the API.
Bug: 366914
EGit-Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This is needed to allow jumping to a selected commit when loading
history incrementally.
Change-Id: Id3b97d88d3b4b2d67561b11f8810cb88fe040823
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Previously if a packed-refs file was racily clean then there
was a 2.5 second window in which each call to getPackedRefs
would increment the mod count causing a RefsChangedEvent to be
fired since the FileSnapshot would report the file as modified.
If a RefsChangedListener called getRef/getRefs from the
onRefsChanged method then a StackOverflowError could occur
since the stack could be exhausted before the 2.5 second
window expired and the packed-refs file would no longer
report being modified.
Now a SHA-1 is computed of the packed-refs file and the
mod count is only incremented when the packed refs are
successfully set and the id of the new packed-refs file
does not match the id of the old packed-refs file.
Change-Id: I8cab6e5929479ed748812b8598c7628370e79697
Previously the index was cleared and updated with a new tree.
Now the commit being reset to and the index are iterated over
in a tree walk and the current index mod time and file length
are copied over to the new dir cache entry being written if
the object ids are the same.
Change-Id: Iaf9e624efb0bf90f9e05fcb0587dde4dec50000c
Overload DirCache.lock to take a repository that is
used for updating smudged index entries with information
from the repository's working tree.
New unit tests are also added for updating smudged index
entries on reset, checkout, and commit.
Change-Id: I88689f26000e4e57e77931e5ace7c804d92af1b6
When reset command was called with tag name as parameter the resulting
HEAD was set to the tag's SHA-1 which is a bug. This patch ensures that
repository.resolve() call always returns commit id.
Change-Id: I219b898c620a75c497c8652dbf4735fd094c4d7c
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If there are a lot of references to modify, using BatchRefUpdate can
save time if the underlying storage is able to combine these updates
together. This should speed up initial clone or fetch into an empty
repository, as some projects can have hundreds of release tags, or
hundreds of branch heads.
Change-Id: Iee9af8d5fa19080077d88357c18853540936e940
clone, fetch and push can all update multiple references in a single
command invocation. Rather than performing sequential iteration
of each reference change inside of the application code, push this
down into the reference database where the implementation can take
advantage of the batch size and optimize itself.
For the local filesystem implementation the obvious optimization
is to write a packed-refs file when the repository is completely
empty. The initial clone, fetch or push into the destination may
have hundreds of new references. Writing all of these as loose
files is not efficient. This optimization is not implemented in
this commit and is left as an exercise for the reader to supply
in a future commit to JGit.
To make the API changes simple, define the BatchRefUpdate type and
implementation using the existing sequential behavior.
Change-Id: I8e1674f091e05e24e3ff56ccbc687a6d18a6a61e
When a command's type is UPDATE, JGit might not yet be sure if it
is a fast-forward or not. Expose a utility method to compute the
exact type by performing the merge base test, allowing the type
to be switched to UPDATE_NONFASTFORWARD if old ObjectId is not
contained in new ObjectId.
BaseReceivePack already does this test when validating the incoming
command list, so provide a package level backdoor to set the type
and avoid needing to redo the merge test later.
Change-Id: If5a6fcc50dc4d6f96e9bb0bb7bba15ebe8b86377
If BaseReceivePack has setAllowNonFastForwards(false) configured
(such as by receive.denynonfastforwards), automatically reject
any command that attempts a non-fast-forward update before it goes
further in processing.
This matches with other checks in validateCommands(), such as the
early failure of delete attempts when isAllowDeletes() is false.
Change-Id: I3bb28e4dd6d17cb31ede09eb84ceb67cdb17ea5d
Matthias Sohn