Cherry-Pick: Support --no-commit

Change-Id: Ic4c313a8971a5aa15745518c49e2587a1a0fe8d4
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Repository.writeMergeHeads to accept a list with subtypes of ObjectId

Allows to pass for example a List<RevCommit>.

Change-Id: I5522707060d7d3e0d848ba579956dc62f8fa0234
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Rebase: Add --preserve-merges support

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>
Preserve merges during pull if configured to do so

Setting branch.<name>.rebase or pull.rebase to 'preserve' will preserve
merges during rebase. Also, pull.rebase is now consulted if there is no
branch-specific configuration.

Bug: 429664
Change-Id: I345fa295c7e774e0d0a8e6aba30fbfc3552e0084
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Don't prefix output from jgit status with '# '

C Git does not do it anymore

Bug: 439937
Change-Id: I20bdb787a00bba3e4adf269fd64ec6296bdc2a66
Update SUBMITTING_PATCHES

It contained outdated information about attaching patches to bug
reports. Shorten it to the essentials.

Also format it using markdown and rename it to CONTRIBUTING.md, which is
a convention and doesn't include "patches" in the name.

Change-Id: I9ee73f16e6fa8fbf529ac0ca791e2375d4d56d68
Signed-off-by: Robin Stocker <robin@nibor.org>
Added the missing export in MANIFEST.MF.

This fixes bug 440352.

Change-Id: I4b1c63087a97b7b2f3d7bdb5e066424a84ef6cef
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Handle initial checkout correctly

As described in native gits file "git-read-tree.txt" git has in a
special mode when doing the "initial" checkout. "Initial" means that the
index is empty before the checkout. This was not handled correctly in
JGit and is fixed in this commit. Also see
https://github.com/git/git/blob/master/Documentation/git-read-tree.txt#L181

Change-Id: I9b9d1bd9ebf349cfca420c891c7b099a18d07ba4
Fix RecursiveMerger's internal use of merge to find a merge base

When RecursiveMerger tried to determine a common base tree it was
recursively tried to merge multiple common bases. But these intermediate
merges which have just been done to determine a single common base for
the final merge already filled some important fields (toBeCheckedOut,
toBeDeleted, ...). These side effects of the intermediate merges led to
wrong results of the final merge. One symptom was that after a recursive
merge which should be succesful you could still see leftover files in
the worktree: files which existed in the (virtual) common base but which
don't exist anymore in the branches to be merged.

The solution is easy: Clear the appropriate fields after common base
determination and start the final merge with a clean state.

Change-Id: I644ea9e1cb15360f7901bc0483cdb9286308c226
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
HistogramDiff: Convert stack recursion to heap managed queue

Each time the longest common substring is found the diff algorithm
recurses to reprocess the regions before and after the common string.

Large files with many edits can trigger StackOverflowError as the
algorithm attempts to process a deeply split tree of regions. This
is especially prone to happen in servers where the Java stack size
may have been limited to 1M or even 256K.

To keep edits produced in order a queue is used to process edits
in a depth-first strategy.

Change-Id: Iae7260c6934efdffac7c7bee4d3633a8208924f7
Fixed message for exception thrown during recursive merge

During recursive merge jgit potentially has to merge multiple
common ancestors. If this fails because there are conflicts then
the exception thrown for that should have a message which states
this clearly. Previously a wrong message was given ("More than 200
merge bases ...")

Change-Id: Ia3c058d5575decdefd50390ed83b63668d31c1d1
RecursiveMerger should not fail on content-merge conflicts of parents

Previously when RecursiveMerger was trying to create a single virtual
common base for the merge it was failing when this lead to content-merge
conflicts. This is different from what native git is doing. When native
git's recursive merge algorithm creates a new common base it will merge
the multiple parents and simply take the merge result (potentially
including conflict markers) as common base. See my discussion with Shawn
here: http://www.spinics.net/lists/git/msg234959.html :

  > - How should workingtree, index (stage1,2,3) look like if during
that
  > merge of common ancestors a conflict occurs? Will I see in stage2
and
  > stage3 really see content of X1 and X2?

  Its done entirely in memory and never touches the working tree or
  index. When a conflict exists in the X1-X2 merge the conflict is
  preserved into the new virtual base.

There is still the possibility that the merge of parents lead to
conflicts. File/Folder conclicts, conflicts on filemodes. This commit
only fixes the situation for conflicts when merging content.

Bug: 438203
Change-Id: If45bc3d078b3d3de87b758e71d7379059d709603
Strip trailing /s in repo base URI.

Change-Id: I71040db2cca69638cfad89acdc9179ee80592b27
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Merge "RecursiveMerger should not fail on content-merge conflicts of parents"
Merge "Added the missing export in MANIFEST.MF."
Remove overlapping submodules from repo manifest.

Apparently repo allows projects overlapping, e.g. one project's path is "foo"
and another project's path is "foo/bar". This is not supported in git submodule.
At JGit repo side we'll skip all the submodules that are in subdirectories of
other submodules, and on repo side we'll make them submodules to resolve this
problem.

Change-Id: I6820c4ef400c530a36150b1228706adfcc43ef64
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Merge "Remove overlapping submodules from repo manifest."
Fix RevertCommand to correctly revert multiple commits at once.

The fix is to move the new head commit to the newly-created revert
commit, so that additional revert commits will use the correct head.

Change-Id: I5de3a9a2a4c276e60af732e9c507cbbdfd1a4652
Signed-off-by: Maik Schreiber <blizzy@blizzy.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Added toString() methods for better debugging of ignore rules

Change-Id: Ie31687faa2df47ecaacace2504c3b4e93f1ea809
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Small performance optimization for ignore rules/fnmatcher

 - don't check empty segments generated by String.split()
 - don't continue to add segments if the matcher fails to match input
 - don't add empty heads
 - don't iterate over empty heads.

Bug: 440732
Change-Id: I7d04dccfe24d91275d17ba246662337d6dba66df
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>