The tests for the merge machinery are spread over several places.
Collect them into t64xx for simplicity. Some notes:
t60[234]*.sh:
Merge tests started in t602*, overgrew bisect and remote tracking
tests in t6030, t6040, and t6041, and nearly overtook replace tests
in t6050. This made picking out relevant tests that I wanted to run
in a tighter loop slightly more annoying for years.
t303*.sh:
These started out as tests for the 'merge-recursive' toplevel command,
but did not restrict to that and had lots of overlap with the
underlying merge machinery.
t7405, t7613:
submodule-specific merge logic started out in submodule.c but was
moved to merge-recursive.c in commit 18cfc08866 ("submodule.c: move
submodule merging to merge-recursive.c", 2018-05-15). Since these
tests are about the logic found in the merge machinery, moving these
tests to be with the merge tests makes sense.
t7607, t7609:
Having tests spread all over the place makes it more likely that
additional tests related to a certain piece of logic grow in all those
other places. Much like t303*.sh, these two tests were about the
underlying merge machinery rather than outer levels.
Tests that were NOT moved:
t76[01]*.sh:
Other than the four tests mentioned above, the remaining tests in
t76[01]*.sh are related to non-recursive merge strategies, parameter
parsing, and other stuff associated with the highlevel builtin/merge.c
rather than the recursive merge machinery.
t3[45]*.sh:
The rebase testcases in t34*.sh also test the merge logic pretty
heavily; sometimes changes I make only trigger failures in the rebase
tests. The rebase tests are already nicely coupled together, though,
and I didn't want to mess that up. Similar comments apply for the
cherry-pick tests in t35*.sh.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are tests which are missing a link in their &&-chain,
but in a way that probably does not effect the outcome of
the test. Most of these are of the form:
some_cmd >actual
test_cmp expect actual
The main point of the test is to verify the output, and a
failure in some_cmd would probably be noticed by bogus
output. But it is good for the tests to also confirm that
"some_cmd" does not die unexpectedly after producing its
output.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of waiting until we record the parents of resulting merge, reduce
redundant parents (including our HEAD) immediately after reading them.
The change to t7602 illustrates the essence of the effect of this change.
The octopus merge strategy used to be fed with redundant commits only to
discard them as "up-to-date", but we no longer feed such redundant commits
to it and the affected test degenerates to a regular two-head merge.
And obviously the known-to-be-broken test in t6028 is now fixed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD). We've hit this while updating
master to origin/master but accidentaly we called (while being on master):
$ git merge master origin/master
Here is a minimal testcase:
$ git init a && cd a
$ echo a >a && git add a
$ git commit -minitial
$ echo b >a && git add a
$ git commit -msecond
$ git checkout master^
$ git merge master master
Fast-forwarding to: master
Already up-to-date with master
Merge made by the 'octopus' strategy.
a | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$ git cat-file commit HEAD
tree eebfed94e75e7760540d1485c740902590a00332
parent bd679e85202280b263e20a57639a142fa14c2c64
author Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
committer Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
Merge branches 'master' and 'master' into HEAD
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This clarifies the logic to omit fast-forward check and omit
trivial merge before running the specified strategy.
The "index_merge" variable started out as a flag to say "do not
do anything clever", but when recursive was changed to skip the
trivial merge, the semantics were changed and the variable alone
does not make sense anymore.
This splits the variable into two, allow_fast_forward (which is
almost always true, and avoids making a merge commit when the
other commit is a descendant of our branch, but is set to false
for ours and subtree) and allow_trivial_merge (which is false
for ours, recursive and subtree).
Unlike the earlier implementation, the "ours" strategy allows an
up-to-date condition. When we are up-to-date, the result will
be our commit, and by definition, we will have our tree as the
result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
