Instead of hard-coding the charset strings "US-ASCII", "UTF-8", and
"ISO-8859-1", use the corresponding constants from StandardCharsets.

UnsupportedEncodingException is not thrown when the StandardCharset
constants are used, so remove the now redundant handling.

Because the encoding names are no longer hard-coded strings, also
remove redundant $NON-NLS warning suppressions.

Also replace existing usages of the constants with static imports.

Change-Id: I0a4510d3d992db5e277f009a41434276f95bda4e
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Set missingOverrideAnnotation=warning in Eclipse compiler preferences
which enables the warning:

  The method <method> of type <type> should be tagged with @Override
  since it actually overrides a superclass method

Justification for this warning is described in:

  http://stackoverflow.com/a/94411/381622

Enabling this causes in excess of 1000 warnings across the entire
code-base. They are very easy to fix automatically with Eclipse's
"Quick Fix" tool.

Fix all of them except 2 which cause compilation failure when the
project is built with mvn; add TODO comments on those for further
investigation.

Change-Id: I5772061041fd361fe93137fd8b0ad356e748a29c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Change-Id: If7b7a90171d1349d634a84f135471ebac29e3210
Signed-off-by: David Pursehouse <david.pursehouse@sonymobile.com>

See the discussion [1] in the Gerrit mailing list.

[1] https://groups.google.com/forum/#!topic/repo-discuss/RRQT_xCqz4o

Change-Id: I2c67384309c5c2e8511a7d0d4e088b4e95f819ff
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

If a non interactive rebase is launched, stopping after a conflict
should set the repository state to RepositoryState.REBASING_MERGE
instead of RepositoryState.REBASING_INTERACTIVE.

Bug: 452623
Change-Id: Ie885aab6d71dabd158a718af0d14fff643c9b850
Also-by: Arthur Daussy <arthur.daussy@obeo.fr>
Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

With --preserve-merges C Git re-does merges using the rewritten merge
parents, discarding the old merge commit. For the common use-case of
pull with rebase this is unfortunate, as it loses the merge conflict
resolution (and other fixes in the merge), which may have taken quite
some time to get right in the first place.

To overcome this we use a two-fold approach:
If any of the (non-first) merge parents of a merge were rewritten, we
also redo the merge, to include the (potential) new changes in those
commits.
If only the first parent was rewritten, i.e. we are merging a branch
that is otherwise unaffected by the rebase, we instead cherry-pick the
merge commit at hand. This is done with the --mainline 1 and --no-commit
options to apply the changes introduced by the merge. Then we set up an
appropriate MERGE_HEAD and commit the result, thus effectively forging a
merge.

Apart from the approach taken to rebase merge commits, this
implementation closely follows C Git. As a result, both Git
implementations can continue rebases of each other.

Preserving merges works for both interactive and non-interactive rebase,
but as in C Git it is easy do get undesired outcomes with interactive
rebase.

CommitCommand supports committing merges during rebase now.

Bug: 439421
Change-Id: I4cf69b9d4ec6109d130ab8e3f42fcbdac25a13b2
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>

Bug: 431214
Change-Id: I295bfdc5751545b046d7fe7efc3f8b39ab4f5415
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Robin Rosennberg <robin.rosenberg@dewire.com>

The folder .git/rebase-merge was not removed in this case. The
repository was then still in rebase state, but neither abort nor
continue worked.

Bug: 425742
Change-Id: I43cea6c9e5f3cef9d6b15643722fddecb40632d9

This came up while testing the proposed buck build for jgit. With buck
we can introduce smaller modules to allow for more concurrency during
build and to better control inner structure of jgit. Trying to put the
porcelain API into a different module than lower level implementation
classes failed since RebaseTodoLine used a porcelain API exception
causing a dependency cycle on the proposed modules. Using an exception
defined on the same abstraction level fixes this problem.

Change-Id: I26a5353e1a8fc23e67d8ce61309bd964f7665bcb
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

Bug: 423670 
Change-Id: Ia6052867f85d4974c4f60ee5a6c820501e8d2427

This feature was introduced in native git with version 1.8.4.

Bug: 422951
Change-Id: I42f194174d64d7ada6631e2156c2a7bf93b5e91c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

With this change jgit checks for uncommitted changes before a rebase is
started. This is also done by native git. One reason is that an abort
would override such changes. The check is skipped for a non-interactive
rebase when it will result in a fast-forward. In this case there can be
only checkout conflicts but no merge conflicts, so there cannot be an
abort which overrides uncommitted changes.

Bug: 422352
Change-Id: I1e0b59b2a4d80a686b67a6729e441924362b1236
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Empty lines of discarded commit messages were added to the commit
message because they were not commented out properly.

Bug: 422246
Change-Id: I263e8a6b30a3392d8b4f09c0695505068a0a485d
Signed-off-by: Stefan Lay <stefan.lay@sap.com>

Bug: 422253
Change-Id: I9739b16c91d2df31a481360a712d3479a4eeee2e
Signed-off-by: Stefan Lay <stefan.lay@sap.com>

If a commit was marked for edit, reword, squash or fixup, but the
interactive rebase stopped because of a conflict, the step was not done
after conflict resolution. This is done now.

Change-Id: If8e7ccc50469165744f2b8a53d180f9ba0f72330
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

When the last step was an edit step, rebase interactive did not finish
after continuing the rebase. Instead, it returned with the status
FAST_FORWARD.

Change-Id: Ib19857474ac089dfeaae665ad5e95c66c21099b0

With the new RebaseResult.EDIT a client can now distinguish if rebase
stopped due to a conflict or because the commit was marked for edit in
an interactive rebase.

Change-Id: I40f2311cf43ed5f290dcda65a7bd85ba770a85f5
Signed-off-by: Stefan Lay <stefan.lay@sap.com>

The rebase command now supports squash and fixup. Both actions are not
allowed as the first step of the rebase.

In JGit, before any rebase step is performed, the next commit is
already cherry-picked. This commit keeps that behaviour. In case of
squash or fixup a soft reset to the parent is perfomed afterwards.

CQ: 7684
Bug: 396510
Change-Id: I3c4190940b4d7f19860e223d647fc78705e57203
Signed-off-by: Tobias Pfeifer <to.pfeifer@web.de>
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

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>

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>

Bug: 346350
Change-Id: I119766a00bc52a810c51cffaa19207cb8555ca22
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Bug: 346350
Change-Id: I119766a00bc52a810c51cffaa19207cb8555ca22
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

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>

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>

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>

Change-Id: Iedb54eb9d8396bc3ae66d8754c1527fd9ca655f9

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

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>

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>

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>

C Git prefixes the time stamp in the author script with a "@"

Change-Id: I140b29519acc101da78296eef562368fc6b61135

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>

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

If after resolving all conflicts nothing is left to commit, return
an according result, so that downstreams (EGit, ...) can behave like
cgit, and display a nice message informing the user.

Currently, EGit displays a "HEAD advanced fast forward" message, which
is absolutely not helpful at all.

This is the basic API revamping required to get that state communicated
to the outside world (EGit).

Bug: 336812
Change-Id: If2665005cf54a5b51c0fe80bad019fa42b0205af

A checkout conflict during rebase setup should leave the repository
in SAFE state which means ensuring that the rebase temporary files
need to be removed.

Bug: 346813
Change-Id: If8b758fde73ed5a452a99a195a844825a03bae1a
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Bug: 344779
Change-Id: I1628984479d93665bf4987d6a4ff8e67ad73eb36
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

In case an underlying cherry-pick fails due to uncommitted changes, a
RebaseCommand shall fail and roll-back changes.

Change-Id: Ic22eb047fb03ac2c8391f777036b7dbf22a1b061
Signed-off-by: Philipp Thun <philipp.thun@sap.com>

This change moves commonly used methods into the RepositoryTestCase
base class.

Change-Id: I56a46c31ee1661c7ce22eb755ab23da8bc9f5da2
Signed-off-by: Philipp Thun <philipp.thun@sap.com>

This bug was hidden by an incomplete test: the current Rebase
implementation using the "git rebase -i" pattern does not work
correctly if fast-forwarding is involved. The reason for this is that
the log command does not return any commits in this case.
In addition, a check for already merged commits was introduced to
avoid spurious conflicts.

Change-Id: Ib9898fe0f982fa08e41f1dca9452c43de715fdb6
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Eclipse has some problem re-running single JUnit tests if
the tests are in Junit 3 format, but the JUnit 4 launcher
is used. This was quite unnecessary and the move was not
completed. We still have no JUnit4 test.

This completes the extermination of JUnit3. Most of the
work was global searce/replace using regular expression,
followed by numerous invocarions of quick-fix and organize
imports and verification that we had the same number of
tests before and after.

- Annotations were introduced.
- All references to JUnit3 classes removed
- Half-good replacement for getting the test name. This was
  needed to make the TestRngs work. The initialization of
  TestRngs was also made lazily since we can not longer find
  out the test name in runtime in the @Before methods.
- Renamed test classes to end with Test, with the exception
  of TestTranslateBundle, which fails from Maven
- Moved JGitTestUtil to the junit support bundle

Change-Id: Iddcd3da6ca927a7be773a9c63ebf8bb2147e2d13
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

This is needed to ensure interoperability with the command line: if
the git-rebase-todo file was created manually (by git rebase -i in the
command line), and any commands other than pick are used (reword,
edit, fixup, squash) JGit must abort as it does not understand these
commands yet.
The same is true if an unknown command is found (e.g. due to a typo);
this is the same behavior as shown by the command line.

Change-Id: I2322014f69460361f7fc09da223e8a5c31f100dd
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Rebase would update the original HEAD to the wrong commit when
"skipping" the last commit after a merged commit.

Includes a test for the specific situation.

Change-Id: I087314b1834a3f11a4561f04ca5c21411d54d993
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

For --continue, the Rebase command asserts that there are no unmerged
paths in the current repository. Then it checks if a commit is needed.
If yes, the commit message and author are taken from the author_script
and message files, respectively, and a commit is performed before the
next step is applied.
For --skip, the workspace is reset to the current HEAD before applying
the next step.

Includes some tests and a refactoring that extracts Strings in the
code into constants.


Change-Id: I72d9968535727046e737ec20e23239fe79976179
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

If the CLI stops a rebase upon conflict, the current
step is already popped from the git-rebase-todo and appended to the
"done" file. The current implementation wrongly pops the step only
after successful cherry-pick.

Change-Id: I8640dda0cbb2a5271ecf75fcbad69410122eeab6
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

The Repository is then in state "Rebase interactive".

Change-Id: I5d2de57f8670e1d4c71ed22509ab17f04e2561b5
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Check for deletion of temporary files in .git folder.
Check for deletion and creation of files.

Change-Id: I60b0b2975724f2e3582e8674d9f876dcbf62b350
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Coverage tests showed that we are missing to test certain areas
in the rebase command. Add the missing tests.

Change-Id: Ia4a272d26cde7e1861dac30496e4b6799fc8187a
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

This is a first iteration to implement Rebase. At the moment, this
does not implement --continue and --skip, so if the first
conflict is found, the only option is to --abort the command.

Bug: 328217
Change-Id: I24d60c0214e71e5572955f8261e10a42e9e95298
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>