1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-14 21:23:03 +01:00
git/t/t3033-merge-toplevel.sh

137 lines
3.8 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='"git merge" top-level frontend'
. ./test-lib.sh
t3033_reset () {
git checkout -B master two &&
git branch -f left three &&
git branch -f right four
}
test_expect_success setup '
test_commit one &&
git branch left &&
git branch right &&
test_commit two &&
git checkout left &&
test_commit three &&
git checkout right &&
test_commit four &&
git checkout master
'
# Local branches
test_expect_success 'merge an octopus into void' '
t3033_reset &&
git checkout --orphan test &&
git rm -fr . &&
test_must_fail git merge left right &&
test_must_fail git rev-parse --verify HEAD &&
git diff --quiet &&
test_must_fail git rev-parse HEAD
'
test_expect_success 'merge an octopus, fast-forward (ff)' '
t3033_reset &&
git reset --hard one &&
git merge left right &&
# one is ancestor of three (left) and four (right)
test_must_fail git rev-parse --verify HEAD^3 &&
git rev-parse HEAD^1 HEAD^2 | sort >actual &&
git rev-parse three four | sort >expect &&
test_cmp expect actual
'
test_expect_success 'merge octopus, non-fast-forward (ff)' '
t3033_reset &&
git reset --hard one &&
git merge --no-ff left right &&
# one is ancestor of three (left) and four (right)
test_must_fail git rev-parse --verify HEAD^4 &&
git rev-parse HEAD^1 HEAD^2 HEAD^3 | sort >actual &&
git rev-parse one three four | sort >expect &&
test_cmp expect actual
'
test_expect_success 'merge octopus, fast-forward (does not ff)' '
t3033_reset &&
git merge left right &&
# two (master) is not an ancestor of three (left) and four (right)
test_must_fail git rev-parse --verify HEAD^4 &&
git rev-parse HEAD^1 HEAD^2 HEAD^3 | sort >actual &&
git rev-parse two three four | sort >expect &&
test_cmp expect actual
'
test_expect_success 'merge octopus, non-fast-forward' '
t3033_reset &&
git merge --no-ff left right &&
test_must_fail git rev-parse --verify HEAD^4 &&
git rev-parse HEAD^1 HEAD^2 HEAD^3 | sort >actual &&
git rev-parse two three four | sort >expect &&
test_cmp expect actual
'
# The same set with FETCH_HEAD
merge: handle FETCH_HEAD internally The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-26 03:47:21 +02:00
test_expect_success 'merge FETCH_HEAD octopus into void' '
t3033_reset &&
git checkout --orphan test &&
git rm -fr . &&
git fetch . left right &&
test_must_fail git merge FETCH_HEAD &&
test_must_fail git rev-parse --verify HEAD &&
git diff --quiet &&
test_must_fail git rev-parse HEAD
'
merge: handle FETCH_HEAD internally The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-26 03:47:21 +02:00
test_expect_success 'merge FETCH_HEAD octopus fast-forward (ff)' '
t3033_reset &&
git reset --hard one &&
git fetch . left right &&
git merge FETCH_HEAD &&
# one is ancestor of three (left) and four (right)
test_must_fail git rev-parse --verify HEAD^3 &&
git rev-parse HEAD^1 HEAD^2 | sort >actual &&
git rev-parse three four | sort >expect &&
test_cmp expect actual
'
merge: handle FETCH_HEAD internally The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-26 03:47:21 +02:00
test_expect_success 'merge FETCH_HEAD octopus non-fast-forward (ff)' '
t3033_reset &&
git reset --hard one &&
git fetch . left right &&
git merge --no-ff FETCH_HEAD &&
# one is ancestor of three (left) and four (right)
test_must_fail git rev-parse --verify HEAD^4 &&
git rev-parse HEAD^1 HEAD^2 HEAD^3 | sort >actual &&
git rev-parse one three four | sort >expect &&
test_cmp expect actual
'
merge: handle FETCH_HEAD internally The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-26 03:47:21 +02:00
test_expect_success 'merge FETCH_HEAD octopus fast-forward (does not ff)' '
t3033_reset &&
git fetch . left right &&
git merge FETCH_HEAD &&
# two (master) is not an ancestor of three (left) and four (right)
test_must_fail git rev-parse --verify HEAD^4 &&
git rev-parse HEAD^1 HEAD^2 HEAD^3 | sort >actual &&
git rev-parse two three four | sort >expect &&
test_cmp expect actual
'
merge: handle FETCH_HEAD internally The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-26 03:47:21 +02:00
test_expect_success 'merge FETCH_HEAD octopus non-fast-forward' '
t3033_reset &&
git fetch . left right &&
git merge --no-ff FETCH_HEAD &&
test_must_fail git rev-parse --verify HEAD^4 &&
git rev-parse HEAD^1 HEAD^2 HEAD^3 | sort >actual &&
git rev-parse two three four | sort >expect &&
test_cmp expect actual
'
test_done