2015-04-29 22:14:50 +02:00
|
|
|
#!/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' '
|
2015-04-29 22:14:50 +02:00
|
|
|
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)' '
|
2015-04-29 22:14:50 +02:00
|
|
|
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)' '
|
2015-04-29 22:14:50 +02:00
|
|
|
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)' '
|
2015-04-29 22:14:50 +02:00
|
|
|
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' '
|
2015-04-29 22:14:50 +02:00
|
|
|
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
|