2015-04-29 22:14:50 +02:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='"git merge" top-level frontend'
|
|
|
|
|
tests: mark tests relying on the current default for `init.defaultBranch`
In addition to the manual adjustment to let the `linux-gcc` CI job run
the test suite with `master` and then with `main`, this patch makes sure
that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts
that currently rely on the initial branch name being `master by default.
To determine which test scripts to mark up, the first step was to
force-set the default branch name to `master` in
- all test scripts that contain the keyword `master`,
- t4211, which expects `t/t4211/history.export` with a hard-coded ref to
initialize the default branch,
- t5560 because it sources `t/t556x_common` which uses `master`,
- t8002 and t8012 because both source `t/annotate-tests.sh` which also
uses `master`)
This trick was performed by this command:
$ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' $(git grep -l master t/t[0-9]*.sh) \
t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh
After that, careful, manual inspection revealed that some of the test
scripts containing the needle `master` do not actually rely on a
specific default branch name: either they mention `master` only in a
comment, or they initialize that branch specificially, or they do not
actually refer to the current default branch. Therefore, the
aforementioned modification was undone in those test scripts thusly:
$ git checkout HEAD -- \
t/t0027-auto-crlf.sh t/t0060-path-utils.sh \
t/t1011-read-tree-sparse-checkout.sh \
t/t1305-config-include.sh t/t1309-early-config.sh \
t/t1402-check-ref-format.sh t/t1450-fsck.sh \
t/t2024-checkout-dwim.sh \
t/t2106-update-index-assume-unchanged.sh \
t/t3040-subprojects-basic.sh t/t3301-notes.sh \
t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \
t/t3436-rebase-more-options.sh \
t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \
t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \
t/t5511-refspec.sh t/t5526-fetch-submodules.sh \
t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \
t/t5548-push-porcelain.sh \
t/t5552-skipping-fetch-negotiator.sh \
t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \
t/t5614-clone-submodules-shallow.sh \
t/t7508-status.sh t/t7606-merge-custom.sh \
t/t9302-fast-import-unpack-limit.sh
We excluded one set of test scripts in these commands, though: the range
of `git p4` tests. The reason? `git p4` stores the (foreign) remote
branch in the branch called `p4/master`, which is obviously not the
default branch. Manual analysis revealed that only five of these tests
actually require a specific default branch name to pass; They were
modified thusly:
$ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\
' t/t980[0167]*.sh t/t9811*.sh
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19 00:44:19 +01:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master
|
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2015-04-29 22:14:50 +02:00
|
|
|
. ./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 &&
|
2016-04-21 20:52:33 +02:00
|
|
|
git checkout --orphan newroot &&
|
merge: refuse to create too cool a merge by default
While it makes sense to allow merging unrelated histories of two
projects that started independently into one, in the way "gitk" was
merged to "git" itself aka "the coolest merge ever", such a merge is
still an unusual event. Worse, if somebody creates an independent
history by starting from a tarball of an established project and
sends a pull request to the original project, "git merge" however
happily creates such a merge without any sign of something unusual
is happening.
Teach "git merge" to refuse to create such a merge by default,
unless the user passes a new "--allow-unrelated-histories" option to
tell it that the user is aware that two unrelated projects are
merged.
Because such a "two project merge" is a rare event, a configuration
option to always allow such a merge is not added.
We could add the same option to "git pull" and have it passed
through to underlying "git merge". I do not have a fundamental
opposition against such a feature, but this commit does not do so
and instead leaves it as low-hanging fruit for others, because such
a "two project merge" would be done after fetching the other project
into some location in the working tree of an existing project and
making sure how well they fit together, it is sufficient to allow a
local merge without such an option pass-through from "git pull" to
"git merge". Many tests that are updated by this patch does the
pass-through manually by turning:
git pull something
into its equivalent:
git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD
If somebody is inclined to add such an option, updated tests in this
change need to be adjusted back to:
git pull --allow-unrelated-histories something
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18 21:21:09 +01:00
|
|
|
test_commit five &&
|
2015-04-29 22:14:50 +02:00
|
|
|
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
|
|
|
|
'
|
|
|
|
|
merge: refuse to create too cool a merge by default
While it makes sense to allow merging unrelated histories of two
projects that started independently into one, in the way "gitk" was
merged to "git" itself aka "the coolest merge ever", such a merge is
still an unusual event. Worse, if somebody creates an independent
history by starting from a tarball of an established project and
sends a pull request to the original project, "git merge" however
happily creates such a merge without any sign of something unusual
is happening.
Teach "git merge" to refuse to create such a merge by default,
unless the user passes a new "--allow-unrelated-histories" option to
tell it that the user is aware that two unrelated projects are
merged.
Because such a "two project merge" is a rare event, a configuration
option to always allow such a merge is not added.
We could add the same option to "git pull" and have it passed
through to underlying "git merge". I do not have a fundamental
opposition against such a feature, but this commit does not do so
and instead leaves it as low-hanging fruit for others, because such
a "two project merge" would be done after fetching the other project
into some location in the working tree of an existing project and
making sure how well they fit together, it is sufficient to allow a
local merge without such an option pass-through from "git pull" to
"git merge". Many tests that are updated by this patch does the
pass-through manually by turning:
git pull something
into its equivalent:
git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD
If somebody is inclined to add such an option, updated tests in this
change need to be adjusted back to:
git pull --allow-unrelated-histories something
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18 21:21:09 +01:00
|
|
|
# two-project merge
|
|
|
|
test_expect_success 'refuse two-project merge by default' '
|
|
|
|
t3033_reset &&
|
|
|
|
git reset --hard four &&
|
|
|
|
test_must_fail git merge five
|
|
|
|
'
|
|
|
|
|
2020-04-07 16:28:07 +02:00
|
|
|
test_expect_success 'refuse two-project merge by default, quit before --autostash happens' '
|
|
|
|
t3033_reset &&
|
|
|
|
git reset --hard four &&
|
|
|
|
echo change >>one.t &&
|
|
|
|
git diff >expect &&
|
|
|
|
test_must_fail git merge --autostash five 2>err &&
|
|
|
|
test_i18ngrep ! "stash" err &&
|
|
|
|
git diff >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
merge: refuse to create too cool a merge by default
While it makes sense to allow merging unrelated histories of two
projects that started independently into one, in the way "gitk" was
merged to "git" itself aka "the coolest merge ever", such a merge is
still an unusual event. Worse, if somebody creates an independent
history by starting from a tarball of an established project and
sends a pull request to the original project, "git merge" however
happily creates such a merge without any sign of something unusual
is happening.
Teach "git merge" to refuse to create such a merge by default,
unless the user passes a new "--allow-unrelated-histories" option to
tell it that the user is aware that two unrelated projects are
merged.
Because such a "two project merge" is a rare event, a configuration
option to always allow such a merge is not added.
We could add the same option to "git pull" and have it passed
through to underlying "git merge". I do not have a fundamental
opposition against such a feature, but this commit does not do so
and instead leaves it as low-hanging fruit for others, because such
a "two project merge" would be done after fetching the other project
into some location in the working tree of an existing project and
making sure how well they fit together, it is sufficient to allow a
local merge without such an option pass-through from "git pull" to
"git merge". Many tests that are updated by this patch does the
pass-through manually by turning:
git pull something
into its equivalent:
git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD
If somebody is inclined to add such an option, updated tests in this
change need to be adjusted back to:
git pull --allow-unrelated-histories something
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-18 21:21:09 +01:00
|
|
|
test_expect_success 'two-project merge with --allow-unrelated-histories' '
|
|
|
|
t3033_reset &&
|
|
|
|
git reset --hard four &&
|
|
|
|
git merge --allow-unrelated-histories five &&
|
|
|
|
git diff --exit-code five
|
|
|
|
'
|
|
|
|
|
2020-04-07 16:28:07 +02:00
|
|
|
test_expect_success 'two-project merge with --allow-unrelated-histories with --autostash' '
|
|
|
|
t3033_reset &&
|
|
|
|
git reset --hard four &&
|
|
|
|
echo change >>one.t &&
|
|
|
|
git diff one.t >expect &&
|
|
|
|
git merge --allow-unrelated-histories --autostash five 2>err &&
|
|
|
|
test_i18ngrep "Applied autostash." err &&
|
|
|
|
git diff one.t >actual &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2015-04-29 22:14:50 +02:00
|
|
|
test_done
|