Bug: 346350
Change-Id: I119766a00bc52a810c51cffaa19207cb8555ca22
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

Use recursive merge as the default strategy since it can successfully
merge more cases than the resolve strategy can. This is also the default
in native Git.

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

A few classes such as Constanrs are marked with @SuppressWarnings, as are
toString() methods with many liternal, but otherwise $NLS-n$ is used for
string containing text that should not be translated. A few literals may
fall into the gray zone, but mostly I've tried to only tag the obvious
ones.

Change-Id: I22e50a77e2bf9e0b842a66bdf674e8fa1692f590

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>

- 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>

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

Bug: 357312
Change-Id: I2f85cf88650594eca7df6aa0e26bea329674f08e

We should see whether the commit was a regular commit or something
else.

Change-Id: I82d8300cf3c53cb2bdcb6495386aadb803e0c6f7
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Add handling of CHERRY_PICK_HEAD file in .git (similar to MERGE_HEAD),
which is written in case of a conflicting cherry-pick merge.

It is used so that Repository.getRepositoryState can return the new
states CHERRY_PICKING and CHERRY_PICKING_RESOLVED. These states, as well
as CHERRY_PICK_HEAD can be used in EGit to properly show the merge tool.

Also, in case of a conflict, MERGE_MSG is written with the original
commit message and a "Conflicts" section appended. This way, the
cherry-picked message is not lost and can later be re-used in the commit
dialog.

Bug: 339092
Change-Id: I947967fdc2f1d55016c95106b104c2afcc9797a1
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

This change contains a simple renaming. Instead of using the
expression 'abnormal failure', we just treat this kind of situation
as 'failure'. This is specific enough as conflicts are already handled
separately.

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

In order to distinguish cherry-pick failures caused by conflicts vs.
'abnormal failures' (e.g. due to unstaged changes or a dirty
worktree), a CherryPickResult class is introduced and returned by
CherryPickCommand.call() instead of a RevCommit. This new class is
similar to MergeResult and RebaseResult. The CherryPickResult contains
all necessary information, e.g. paths causing the cherry-pick (a merge
called within, respectively) to fail. This allows callers to better
react on failures.

Change-Id: I5db57b9259e82ed118e4bf4ec94463efe68b8c1f
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Instead just return success. In the case that no commit has been
cherry-picked or reverted, just return the old HEAD.
    
Bug: 333814
Change-Id: I67db2b77b52c43932436d22a8daa5a6556423484
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

Implemented the initial version of a cherry-pick command.
A correct error handling is missing (what happens if the
checkout fails, the cherry-pick leads to conflicts etc).
But straightforward cherry-picks works.

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