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

This fixes two cases:
- A folder without tracked content exist both in the workdir and merged
commit, as long as there names within that folder does not conflict.
- An empty folder structure exists with the same name as a file in the
merged commit.

Bug: 402834
Change-Id: I4c5b9f11313dd1665fcbdae2d0755fdb64deb3ef

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>

Change-Id: Iedb54eb9d8396bc3ae66d8754c1527fd9ca655f9

In case of a conflict during cherry-pick or revert the commit message
was amended after the footer. This made the footer invalid. Many users
do not understand that they have to edit the commit message in order to
make it valid again.

Change-Id: I7e7fae125129e2a0d8950510550acda766531835
Bug: 367416

Change-Id: I83ca25fb569c0dbc36eb374d5437fcf2b65a6f68

Change-Id: I6e6522289553137df1a46ceeb52f461e9d25a290

By making use of JUnit Theories and Datapoints ResolveMergerTests is now
capable to run the tests against multiple Merge strategies.

Change-Id: Ifa0075e0a2aca7576ef268291b73fa2f4d79b591

This case breaks when the default is to disallow empty commits.

Change-Id: Ibc223092eefe9f4b21374717dee5a9399bf890f9

That is the common style and yields better diagnostics on failure.

Change-Id: I831a55615a812734af0912a5d6bbfd1edc75308e

Currently, after a merge/cherry-pick/rebase, all index entries are
smudged as the ResolveMerger never sets entry lengths and/or
modification times. This change teaches it to re-set them at least for
things it did not touch. The other entries are then repaired when the
index is persisted, or entries are checked out.

The first attempt to get this in was commit
3ea694c252 which has been reverted.
Since then some fixes to ResolveMerger and a few more tests have
been added which check situations where the index is not matching
HEAD before we merge.

Change-Id: I648fda30846615b3bf688c34274c6cf4bc857832
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Also-by: Markus Duft <markus.duft@salomon.at>

This reverts commit 3ea694c252

Merges with unmodified subtrees are broken with this commit present.
Back it out until a fixed version can be supplied.

Currently, after a merge/cherry-pick/rebase, all index entries are
smudged as the ResolveMerger never sets entry lengths and/or
modification times. This change teaches it to re-set them at least for
things it did not touch. The other entries are then repaired when the
index is persisted, or entries are checked out.

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

ResolveMerger#mergeImpl() was only returning false (= failed) when there
were unmerged paths. In the case when there were only failing paths, it
returned true.

Because MergeCommand looks at the return value for determining if the
merge failed, it would fall into the successful case there, where it
should instead return a MergeResult with MergeStatus.FAILED.

This change adds a test case for this and makes the ResolveMerger return
false when there are failing paths.

This was discovered while working on fixing bug 354099 and is needed for
its test case.

Bug: 354099
Change-Id: I499f518f6289ef93e017db924b2aa857f2154707
Signed-off-by: Robin Stocker <robin@nibor.org>

CQ: 6570
Bug: 351806
Change-Id: I5e47810376419264ecf4247b5a333af5c8945080
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Commit 13931236b9 in C Git (2011-11-02)
changed the message format:

-Merge remote branch 'origin/foo'
+Merge remote-tracking branch 'origin/foo'

This change does the same in EGit to be consistent.

Change-Id: I7d9c5afa95771dbfe6079b5f89a10b248fee0172
Signed-off-by: Robin Stocker <robin@nibor.org>

Previously when merging two contents with a non-empty base and one of
the contents was empty (size == 0) and the other was modified there
was a potentially expensive calculation until we finally always come
to the same result -> the complete non-deleted content should collide
with the empty content.

This proposal adds an optimization to detect empty input content and
to produce the appropriate result immediatly.

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

Merging into a non-master branch would result in the following message:

  Merge branch 'a' into HEAD

Now the merge message is correct:

  Merge branch 'a' into b

Change-Id: I488f97190e4c1711c23a7a3cbd64f8b13a87bbac
Signed-off-by: Robin Stocker <robin@nibor.org>

The mapTree() routines have been deprecated for a long time, and their
sibilings for mapCommit() and mapTag() were already removed from the
main Repository API.

Remove mapTree().  Application callers who only need the tree's name
can use resolve("^{tree}") syntax to resolve to the tree ObjectId, or
fail if the input is not a tree.

Applications that want to read a tree should use DirCache or TreeWalk.

Change-Id: I85726413790fc87721271c482f6636f81baf8b82
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

When MergeMessageFormatter was given a symbolic ref HEAD which points to
refs/heads/master (which is the case when merging a branch in EGit), it
would result in a merge message like the following:

  Merge branch 'a' into HEAD

But it should print the following (as C Git does):

  Merge branch 'a'

The solution is to use the leaf ref when checking for refs/heads/master.

Change-Id: I28ae5713b7e8123a0176fc6d7356e469900e7e97

This is almost reverted cherry-pick, and the implementation is
almost identical. It orders the input to merge differently to get
the effect and produces a different commit message with the
default author, rather than the original author.

Change-Id: I39970091d9f7406ae7168b8efaab23a5e2c16bad
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.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>

The referenced bug showed that JGit produced different merge results
compared to C Git. Unit test was added to reproduce the issue. The
problem can be solved by switching to histogram diff algorithm.

Bug: 331078
Change-Id: I54f30afb3a9fef1dbca365ca5f98f4cc846092e3
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Philipp Thun <philipp.thun@sap.com>

The diff algorithm which is used by Merge, Cherry-Pick, Rebase
should be configurable. A new configuration parameter "diff.algorithm"
is introduced which currently accepts the values "myers" or
"histogram". Based on this parameter for example the ResolveMerger
will choose a diff algorithm. The reason for this is bug 331078.
This bug shows that JGit is more compatible with C Git when
histogram diff is in place. But since histogram diff is quite new we
need an easy way to fall back to Myers diff.

Bug: 331078
Change-Id: I2549c992e478d991c61c9508ad826d1a9e539ae3
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Philipp Thun <philipp.thun@sap.com>

The automatically generated commit message of a merge should have the
same structure as in C Git for consistency (as per git fmt-merge-msg).

Before this change:

  merging refs/heads/a into refs/heads/master

After:

  Merge branch 'a'

Plurals, "into" and joining by "," and "and" also work.

Change-Id: I9658ce2817adc90d2df1060e8ac508d7bd0571cb

JGit merge algorithm behaved differently from C Git when
we had adjacent modifications. If line 9 was modified by
OURS and line 10 by theirs then C Git will return a
conflict while JGit was seeing this as independent
modifications. This change is not only there to achieve
compatibility, but there where also some really wrong
merge results produced by JGit in the area of adjacent
modifications.

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

Introduced similar helper methods than in AbstractDiffTestCase.
Then the test cases are much smaller and better understandable.

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

As described in Bug 328551 there was a bug that the merge algorithm
was not always reporting conflicts when the same line was deleted
and modified. This problem was introduced during commit
0c017188b4 when reported conflicts have
been checked for common pre- and suffixes.

This was fixed here by better determining whether after stripping
off common prefixes and suffixes from a conflicting region there
is still some conflicting part left.
I also added a unit test to test this situation.

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

Instead of making the sequence itself responsible for the equivalence
function, use an external function that is supplied by the caller.
This cleans up the code because we now say cmp.equals(a, ai, b, bi)
instead of a.equals(ai, b, bi).

This refactoring also removes the odd concept of creating different
types of sequences to have different behaviors for whitespace
ignoring.  Instead DiffComparator now supports singleton functions
that apply a particular equivalence algorithm to a type of sequence.

Change-Id: I559f494d81cdc6f06bfb4208f60780c0ae251df9
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The merge algorithm was reporting conflicts which where to big.

Example: The common base was "ABC", the "ours" version contained
"AB1C" (the addition of "1" after pos 2) and the "theirs" version also
contained "AB1C". We have two potentially conflicting edits in the
same region which happen to bring in exactly the same content. This
should not be a conflict - but was previously reported as
"AB<<<1===1>>>C".

This is fixed by checking every conflicting chunk whether the
conflicting regions have a common prefix or suffix and by removing
this regions from the conflict.

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

These objects should be responsible for their own formatting,
rather than delegating it to some obtuse type called ObjectInserter.

While we are at it, simplify the way we insert these into a database.
Passing in the type and calling format in application code turned
out to be a huge mistake in terms of ease-of-use of the insert API.

Change-Id: Id5bb95ee56aa2a002243e9b7853b84ec8df1d7bf
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Since these types no longer support reading, calling them a Builder
is a better description of what they do.  They help the caller to
build a commit or a tag object.

Change-Id: I53cae5a800a66ea1721b0fe5e702599df31da05d
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The Commit class now only supports the creation of a commit object.
To read a commit, applictions should use RevCommit.  This permits
us to have exactly one implementation, and RevCommit's is faster
and more bug-free.

Change-Id: Ib573f7e15f36855112815269385c21dea532e2cf
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Instead of creating the DirCache from a static factory method, use
an instance method on Repository, permitting the implementation to
override the method with a completely different type of DirCache
reading and writing.  This would better support a repository in the
cloud strategy, or even just an in-memory unit test environment.

Change-Id: I6399894b12d6480c4b3ac84d10775dfd1b8d13e7
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Some newer style APIs are updated to use the newer ObjectInserter
interface instead of the now deprecated ObjectWriter.  In many of
the unit tests we don't bother to release the inserter, these are
typically using the file backend which doesn't need a release,
but in the future should use an in-memory HashMap based store,
which really wouldn't need it either.

Change-Id: I91a15e1dc42da68e6715397814e30fbd87fa2e73
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Adds the file content merge alorithm and tests for merge to jgit.
The merge algorithm:

- Gets as input parameters the common base, the two new contents
  called "ours" and "theirs".

- Computes the Edits from base to ours and from base to theirs with
  the help of MyersDiff.

- Iterates over the edits.

- Independent edits from ours or from theirs will just be applied
  to the result.

- For conflicting edits we first harmonize the ranges of the edits
  so that in the end we have exactly two edits starting and ending
  at the same points in the common base. Then we write the two
  conclicting contents into the result stream.

Change-Id: I411862393e7bf416b6f33ca55ec5af608ff4663
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
[sp: Fixed up two awkard comments in documentation.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Not all of our test cases really require the sample data packs,
and we are better off not using them because its hard to see exactly
what condition a test is testing when looking only at the Java code.
Clarify the dependency by only making the packs available when
there is a real need for it.

Change-Id: Id8a76ee7ee1f7efba585be4bed19a8fb5b3b3585
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Per CQ 3448 this is the initial contribution of the JGit project
to eclipse.org.  It is derived from the historical JGit repository
at commit 3a2dd9921c.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>