Move the set constructor function to a Sets utility class,
allowing the tests to compile in parallel.
Change-Id: Id6fac2533fab8d423f949c892f199af2491a450b
Reference the resource from the root of the CLASSPATH, allowing the
test classes to be compiled in parallel with no dependencies.
Change-Id: Ia6becf30ccfe93b8585b82293d9a4863b0cf837e
Parse commitId and shortMessage of a commented out line in rebase todo
A rebase todo file consists of regular non-comment action lines and
comment lines. In case that a regular action line has been commented out
(i.e. prefixed with a hash '#'), the RebaseTodoLine that is representing
this line should hold the values for commitId and shortMessage even
though it's a comment line. This allows to switch between comment and
non-comment easily even after the file has been persisted and reread.
Change-Id: I56ec2ba08eaf3772e2d74d937dd496209a744d4b
Signed-off-by: Tobias Pfeifer <to.pfeifer@web.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Enhance reading of git-rebase-todo formatted files
Reading and writing files formatted like the git-rebase-todo files was
hidden in the RebaseCommand. Certain constructs (like leading tabs and
spaces) have not been handled as in native git. Also the upcoming
rebase interactive feature in EGit needs reading/writing these files
independently from a RebaseCommand.
Therefore reading and writing those files has been moved to the
Repository class. RebaseCommand gets smaller because of that and doesn't
have to deal with reading/writing files.
Additional tests for empty todo-list files, or files containing comments
have been added.
Change-Id: I323f3619952fecdf28ddf50139a88e0bea34f5ba
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Also-by: Tobias Pfeifer <to.pfeifer@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ResetCommand: Allow reset on unborn branch when ref not specified
In C Git 1.8.2, "git reset" now also works on an unborn branch (no HEAD
yet) if no explicit ref was specified. In that case, it is treated as a
reset to an empty tree.
This can be useful for callers because "unborn branch" no longer has to
be special-cased to "git rm --cached".
Bug: 414870
Change-Id: Ied750116f767518ae4d48823cf00752b049a8477
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Without update, index is wrongly detected to be dirty
when picking the second commit.
Change-Id: Idf47ecb33e8bd38340d760806d629f67be92d2d5
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Bug: 411963
Enable LsRemoteCommand to work without local repository
It's supported by C Git and can be useful.
Bug: 413388
Change-Id: I12c6c10e791cc09ee271d89eb8b8d32f53e385db
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Allow filtering of the status. Only files which match given paths are
inspected and only their state is reported.
Change-Id: I3c4b1b46bf297cd4ebdb4997cfa14c8752a36411
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Without update, index is wrongly detected to be dirty
when picking the second commit.
Change-Id: Idf47ecb33e8bd38340d760806d629f67be92d2d5
Signed-off-by: Hiroshi Tomita <tomykaira@gmail.com>
Bug: 411963
Make JGit test work with both hamcrest 1.1 (juno) and 1.3 (kepler)
The hamcrest library has moved things around. This problem applies only
to the test, not plugin runtime.
Change-Id: I5b97f356d8595dbdc9e91d157558e40561a6a30d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Handle short branch/tag name for setBranch in CloneCommand
Before, it was not clear from the documentation what kind of branch name
was accepted. Users specifying "branch" (instead of "refs/heads/branch")
got no error message and ended up with a repository without HEAD and no
checkout.
With this, CloneCommand now tries "$branch", then "refs/heads/$branch"
and then "refs/tags/$branch". C Git only does the last two, but for
compatibility we should still allow "refs/heads/branch".
Bug: 390994
Change-Id: I4be13144f2a21a6583e0942f0c7c40da32f2247a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
There was a severe bug in CommitCommand which could corrupt
repos. When merging an annotated tag the JGit MergeCommand writes
correctly the ID of the tag (and not the id of the commit the tag was
pointing to) into MERGE_HEAD. Native git does the same. But
CommitCommand was reading this file and trusting blindly that it will
contain only IDs of commits. Then the CommitCommand created a
commit which has as parent a non-commit object (the tag object). That's
so corrupt that even native git gives up when you call "git log" in
such a repo.
To reproduce that with EGit simply right-click on a tag in the
Repository View and select Merge. The result was a corrupt repo!
Bug: 336291
Change-Id: I24cd5de19ce6ca7b68b4052c9e73dcc6d207b57c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Update tags on fetch if --tags or tag refspec specified
When either --tags or a tag ref is explicitly specified on fetch, C Git
updates existing local tags if they are different.
Before this change, JGit returned REJECTED in such a case. Now it
updates it and returns FORCED.
Example:
% mkdir a
% cd a
% git init -q
% touch test.txt
% git add test.txt
% git commit -q -m 'Initial'
% git tag v1
% cd ..
% git clone -q a b
% cd a
% echo Test > test.txt
% git commit -q -a -m 'Second'
% git tag -f v1
Updated tag 'v1' (was bc85c08)
% cd ../b
% git fetch --tags
- [tag update] v1 -> v1
Bug: 388095
Change-Id: I5d5494c2ad1a2cdb8e9e614d3de445289734edfe
Only fetch tags that do not exist locally with auto-follow
This corresponds to what C Git does, quoting from the fetch man page:
This is done by first fetching from the remote using the given
<refspec>s, and if the repository has objects that are pointed by
remote tags that it does not yet have, then fetch those missing tags.
Before, JGit would also fetch tags that exist locally but point to a
different object, resulting in REJECTED results for these.
Also add some test cases to cover more cases.
Bug: 388095
Change-Id: Ib03d2d82e9c4b60179d626cfd5174be1da6388b2
Also-by: Stefan Lay <stefan.lay@sap.com>
Added also tests and the associated option for the command line Merge
command.
Bug: 335091
Change-Id: Ie321c572284a6f64765a81674089fc408a10d059
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
LogCommand.all(): filter out refs that do not refer to commit objects
1. I have authored 100% of the content I'm contributing,
2. I have the rights to donate the content to Eclipse,
3. I contribute the content under the EDL
Change-Id: I48b1828e0b1304f76276ec07ebac7ee9f521b194
LogCommand.all(), peel references before using them
Problem:
LogCommand.all() throws an IncorrectObjectTypeException when
there are tag references, and the repository does not contain
the file "packed-refs". It seems that the references were not properly
peeled before being added to the markStart() method.
Solution:
Call getRepository().peel() on every Ref that has isPeeled()==false
in LogCommand.all() .
Added test case for LogCommand.all() on repo with a tag.
1. I have authored 100% of the content I'm contributing,
2. I have the rights to donate the content to Eclipse,
3. I contribute the content under the EDL
Bug: 402025
Change-Id: Idb8881eeb6ccce8530f2837b25296e8e83636eb7
JGit 3.0: move internal classes into an internal subpackage
This breaks all existing callers once. Applications are not supposed
to build against the internal storage API unless they can accept API
churn and make necessary updates as versions change.
Change-Id: I2ab1327c202ef2003565e1b0770a583970e432e9
Support aborting non-interactive rebase started from C Git
Continuing is trickier, as .git/rebase-apply contains no message file
and no git-rebase-todo.
Bug: 336820
Change-Id: I4eb87c850078ca187b38b81cc91c92afb1176945
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
NameRevCommand: Don't use merge cost for first parent
Treat first parent traversals as 1 and higher parents as MERGE_COST,
to match git name-rev. Allow overriding the merge cost during tests to
avoid creating 2^16 commits on the fly.
Change-Id: I0175e0c3ab1abe6722e4241abe2f106d1fe92a69
NameRevCommand: Use ~ notation for first parents of merges
Prefer ~(N+1) to ^1~N. Although both are correct, the former is
cleaner and matches "git name-rev".
Change-Id: I772001a219e5eb346f5552c92e6d98c70b2cfa98
Add a NameRevCommand for describing IDs in terms of refnames
The walk logic does not use RevWalk because it needs to walk all paths
to each of the requested commits, keeping track of each path along which
the commit was found in the RevCommit subclass. From these paths, a
single "best" path is chosen based on the total path length, with a
penalty applied for paths that traverse merges.
This functionality parallels "git name-rev".
Change-Id: I92bfb47dd16c898313d2ee525395609c3bf72ebe
Rebase computes the list of commits that are included in
the merges, just like Git does, so do not try to include
the merge commits. Re-recreating merges during rebase is
a bit more complicated and might be a useful future extension,
but for now just linearize during rebase.
Change-Id: I61239d265f395e5ead580df2528e46393dc6bdbd
Signed-off-by: Robin Stocker <robin@nibor.org>
CloneCommand has been creating fetch refspecs like this on bare clones:
[remote "origin"]
url = ssh://example.com/my-repo.git
fetch = +refs/heads/*:refs/heads//*
As you can see, the destination ref pattern has a superfluous slash.
It looks like this behaviour has always been the case for CloneCommand,
at least since cc2197ed when code catering to bare-clone fetch refspecs
was added. That was released with JGit v1.0 almost 2 years ago, so
there will probably be some bare repos in the wild which will have been
cloned with JGit and have these corrupted refspecs.
The effect of the corrupted fetch refspec is quite interesting. Up to
and including JGit 2.0, the corrupt refspec was tolerated and fetches
would work as intended with no indication to the user that anything was
amiss. With JGit 2.1, a change was introduced which made JGit less
tolerant, and fetches now attempt to update the non-existing ref
"refs/heads//master". No exception is raised, but the real ref -
"refs/heads/master" - is not updated.
This behaviour was noticed by a user of Agit (which does bare clones by
default and recently updated from JGit v2.0 to v2.2), reported here:
https://github.com/rtyley/agit/issues/92
If you run C-Git fetch on a bare-repo cloned by JGit, it flat-out
rejects the refspec (checked against v1.7.10.4):
fatal: Invalid refspec '+refs/heads/*:refs/heads//*'
Incidentally, C-Git does not create an explicit fetch refspec at all
when performing a bare clone - the full remote config generated by C-Git
looks like this:
[remote "origin"]
url = ssh://example.com/my-repo.git
Using JGit on such a repository works fine, so omitting the fetch
refspec entirely is also an option.
Change-Id: I14b0d359dc69b8908f68e02cea7a756ac34bf881
Instead of the complicated strange stuff, implement staah
apply as cherry-pick.
Provided there are no conflicts and it is requested that
the index should be applied, perform yet another cherry-pick,
but discard tha results thereof it that would result in conflicts.
Bug: 376035
Change-Id: I553f3a753e0124b102a51f8edbb53ddeff2912e2
Previously the result of an application would have been \r\r\n in the
case of windows line endings, as RawText does not touch the \r, and
ApplyCommand adds "\r\n" if this is the ending of the first line in the
target file. Only always adding \n should be ok, since \r\n would be the
result if the file and the patch include windows line endings.
Also add according test.
Change-Id: Ibd4c4948d81bd1c511ecf5fd6c906444930d236e
This converts a checkout conflict exception into a RebaseResult /
MergeResult containing the conflicting paths, which enables EGit (or
others) to handle the situation in a user-friendly way
Change-Id: I48d9bdcc1e98095576513a54a225a42409f301f3
Update the revert command and things relating to revert
Cherry-pick has been fixed, but even though revert does
basically the same thing, the fixes were not carried over here.
- Recognize the revert-states, analogous to the cherry picking states
- Make reset handle a revert-in-progress
- Update REVERT_HEAD and MERGE_MSG when revert fails due to conflicts
- Clear revert state on commit and reset
- Format the message similarily to how cherry-pick does. This is
not exactly how C Git does it.
The interface is still not the same as for cherry-picking.
Change-Id: I8ea956fcbc9526d62a2365360feea23a9280eba3
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>
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>
Add support for rebase interactive 'reword' command
'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>
Shawn Pearce
Tobias Pfeifer
Christian Halstrick
Matthias Sohn
Kohsuke Kawaguchi
Robin Stocker
Robin Rosenberg
Hiroshi Tomita
Tomasz Zarna
Arthur Baars
Shawn Pearce
Dave Borowitz
Roberto Tyley
Markus Duft
Dariusz Luksza
Mikael Karlsson