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

37a1e4be moved this constant causing the following error message in
Eclipse: "The static field LocalDiskRepositoryTestCase.CONTENT should be
accessed directly".

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

When RecursiveMerger found that there are multiple base-commits for the
commits to be merged it tries to temporarily merge the base commits. But
if these base commits have no common predecessor there was a bug in JGit
leading to a NPE. This commit fixes this by enforcing that an empty tree
is used as base when merging two unrelated base commits.

This logic was already there when merging two commits which have no
common predecessor (ThreeWayMerger.mergeBase()). But the code which was
computing a new temporary base commit in case of criss-cross merges
didn't take care to pick an empty tree when no common predecessor can be
found.

Bug: 462671
Change-Id: Ibd96302f5f81383f36d3b1e3edcbf5822147b1a4

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

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>

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

Extend ResolveMerger with RecursiveMerger to merge two tips
that have up to 200 bases.

Bug: 380314
CQ: 6854
Change-Id: I6292bb7bda55c0242a448a94956f2d6a94fddbaa
Also-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>