mirrors/git
1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-09 02:33:11 +01:00
Code Activity
git/t/t6028-merge-up-to-date.sh

93 lines
1.7 KiB
Bash
Raw Normal View History

git-merge: do up-to-date check also for all strategies 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>
2007-08-16 08:19:55 +02:00
#!/bin/sh
Use 'fast-forward' all over the place It's a compound word. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-24 10:31:32 +02:00
test_description='merge fast-forward and up to date'
git-merge: do up-to-date check also for all strategies 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>
2007-08-16 08:19:55 +02:00
. ./test-lib.sh
test_expect_success setup '
>file &&
git add file &&
test_tick &&
git commit -m initial &&
git tag c0 &&
echo second >file &&
git add file &&
test_tick &&
git commit -m second &&
git tag c1 &&
merge tests: octopus with redundant parents 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>
2012-02-13 12:48:56 +01:00
git branch test &&
echo third >file &&
git add file &&
test_tick &&
git commit -m third &&
git tag c2
git-merge: do up-to-date check also for all strategies 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>
2007-08-16 08:19:55 +02:00
'
test_expect_success 'merge -s recursive up-to-date' '
git reset --hard c1 &&
test_tick &&
git merge -s recursive c0 &&
expect=$(git rev-parse c1) &&
current=$(git rev-parse HEAD) &&
test "$expect" = "$current"
'
test_expect_success 'merge -s recursive fast-forward' '
git reset --hard c0 &&
test_tick &&
git merge -s recursive c1 &&
expect=$(git rev-parse c1) &&
current=$(git rev-parse HEAD) &&
test "$expect" = "$current"
'
test_expect_success 'merge -s ours up-to-date' '
git reset --hard c1 &&
test_tick &&
git merge -s ours c0 &&
expect=$(git rev-parse c1) &&
current=$(git rev-parse HEAD) &&
test "$expect" = "$current"
'
test_expect_success 'merge -s ours fast-forward' '
git reset --hard c0 &&
test_tick &&
git merge -s ours c1 &&
expect=$(git rev-parse c0^{tree}) &&
current=$(git rev-parse HEAD^{tree}) &&
test "$expect" = "$current"
'
test_expect_success 'merge -s subtree up-to-date' '
git reset --hard c1 &&
test_tick &&
git merge -s subtree c0 &&
expect=$(git rev-parse c1) &&
current=$(git rev-parse HEAD) &&
test "$expect" = "$current"
'
builtin/merge.c: reduce parents early 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>
2012-04-17 21:22:26 +02:00
test_expect_success 'merge fast-forward octopus' '
merge tests: octopus with redundant parents 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>
2012-02-13 12:48:56 +01:00
git reset --hard c0 &&
test_tick &&
git merge c1 c2
expect=$(git rev-parse c2) &&
current=$(git rev-parse HEAD) &&
test "$expect" = "$current"
'
git-merge: do up-to-date check also for all strategies 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>
2007-08-16 08:19:55 +02:00
test_done
Copy permalink