Added the missing export in MANIFEST.MF.

This fixes bug 440352.

Change-Id: I4b1c63087a97b7b2f3d7bdb5e066424a84ef6cef
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
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>
Mark package org.eclipse.jgit.gitrepo.internal as x-internal

It's an internal package which isn't part of the API. Mark it x-internal
to silence @since tag warnings which are only raised for new API.

Bug: 440757
Change-Id: Id05deaca43f135cd1bfe83cf1f29787cbbdbecac
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Remove @Override annotation illegal for interfaces on Java 5

Bug: 440757
Change-Id: I11897e8e680722313f28d9d241e23e92eddeb966
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Implement RepoCommand.Project.hashCode() since we override equals()

Bug: 440757
Change-Id: I16614c75b62b2fbef05419dd8667e3c50889abe4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix API errors raised on ResolveMerger affecting API providers only

In change If45bc3d078b3d3de87b758e71d7379059d709603 a new parameter was
added to 3 protected methods of ResolveMerger. This breaks the code of
developers which have subclassed ResolveMerger. The API baseline check
in Eclipse reports this as API breakage.

Since this will break only providers but not consumers of the API this
should be allowed also in minor versions. According to OSGi semantic
versioning
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
breaking providers in a minor version update is ok.

Therefore silence these errors using API filter rules.

Bug: 440757
Change-Id: Icabbd0e1de7e877c66a5c4a2c8391473f992a1aa
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix Javadoc errors with Java 8

Bug: 440414
Change-Id: Icce87bd23a3698513b76246677f1d45ddbcaab47
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Merge "HistogramDiff: Convert stack recursion to heap managed queue"
IndexDiffFilter should never filter entries with stage!=0

If the IndexDiffFilter is asked whether it should include or filter out
a certain path and for that path there is a dircache entry with a stage
different from 0, then the filter should never filter out this entry.
IndexDiffFilter is an optimized version of AnyDiffFilter and there is no
case where the index contains non-0 stages but we still don't see any
diff for that path.

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