2007-01-15 14:00:02 +08:00
|
|
|
#!/bin/sh
|
|
|
|
|
2023-04-30 18:00:34 +08:00
|
|
|
test_description='miscellaneous basic tests for cherry-pick and revert'
|
2007-01-15 14:00:02 +08:00
|
|
|
|
2020-11-19 07:44:26 +08:00
|
|
|
GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main
|
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 07:44:19 +08:00
|
|
|
export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME
|
|
|
|
|
2023-02-07 03:08:08 +08:00
|
|
|
TEST_PASSES_SANITIZE_LEAK=true
|
2007-01-15 14:00:02 +08:00
|
|
|
. ./test-lib.sh
|
|
|
|
|
|
|
|
test_expect_success setup '
|
|
|
|
|
|
|
|
for l in a b c d e f g h i j k l m n o
|
|
|
|
do
|
2021-12-09 13:11:12 +08:00
|
|
|
echo $l$l$l$l$l$l$l$l$l || return 1
|
2007-01-15 14:00:02 +08:00
|
|
|
done >oops &&
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
git add oops &&
|
|
|
|
git commit -m initial &&
|
|
|
|
git tag initial &&
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
echo "Add extra line at the end" >>oops &&
|
|
|
|
git commit -a -m added &&
|
|
|
|
git tag added &&
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
git mv oops spoo &&
|
|
|
|
git commit -m rename1 &&
|
|
|
|
git tag rename1 &&
|
|
|
|
|
|
|
|
test_tick &&
|
|
|
|
git checkout -b side initial &&
|
|
|
|
git mv oops opos &&
|
|
|
|
git commit -m rename2 &&
|
|
|
|
git tag rename2
|
|
|
|
'
|
|
|
|
|
2010-06-14 13:32:09 +08:00
|
|
|
test_expect_success 'cherry-pick --nonsense' '
|
|
|
|
|
|
|
|
pos=$(git rev-parse HEAD) &&
|
|
|
|
git diff --exit-code HEAD &&
|
|
|
|
test_must_fail git cherry-pick --nonsense 2>msg &&
|
|
|
|
git diff --exit-code HEAD "$pos" &&
|
t: don't spuriously close and reopen quotes
In the test scripts, the recommended style is, e.g.:
test_expect_success 'name' '
do-something somehow &&
do-some-more testing
'
When using this style, any single quote in the multi-line test section
is actually closing the lone single quotes that surround it.
It can be a non-issue in practice:
test_expect_success 'sed a little' '
sed -e 's/hi/lo/' in >out # "ok": no whitespace in s/hi/lo/
'
Or it can be a bug in the test, e.g., because variable interpolation
happens before the test even begins executing:
v=abc
test_expect_success 'variable interpolation' '
v=def &&
echo '"$v"' # abc
'
Change several such in-test single quotes to use double quotes instead
or, in a few cases, drop them altogether. These were identified using
some crude grepping. We're not fixing any test bugs here, but we're
hopefully making these tests slightly easier to grok and to maintain.
There are legitimate use cases for closing a quote and opening a new
one, e.g., both '\'' and '"'"' can be used to produce a literal single
quote. I'm not touching any of those here.
In t9401, tuck the redirecting ">" to the filename while we're touching
those lines.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-07 04:08:53 +08:00
|
|
|
test_i18ngrep "[Uu]sage:" msg
|
2010-06-14 13:32:09 +08:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'revert --nonsense' '
|
|
|
|
|
|
|
|
pos=$(git rev-parse HEAD) &&
|
|
|
|
git diff --exit-code HEAD &&
|
|
|
|
test_must_fail git revert --nonsense 2>msg &&
|
|
|
|
git diff --exit-code HEAD "$pos" &&
|
t: don't spuriously close and reopen quotes
In the test scripts, the recommended style is, e.g.:
test_expect_success 'name' '
do-something somehow &&
do-some-more testing
'
When using this style, any single quote in the multi-line test section
is actually closing the lone single quotes that surround it.
It can be a non-issue in practice:
test_expect_success 'sed a little' '
sed -e 's/hi/lo/' in >out # "ok": no whitespace in s/hi/lo/
'
Or it can be a bug in the test, e.g., because variable interpolation
happens before the test even begins executing:
v=abc
test_expect_success 'variable interpolation' '
v=def &&
echo '"$v"' # abc
'
Change several such in-test single quotes to use double quotes instead
or, in a few cases, drop them altogether. These were identified using
some crude grepping. We're not fixing any test bugs here, but we're
hopefully making these tests slightly easier to grok and to maintain.
There are legitimate use cases for closing a quote and opening a new
one, e.g., both '\'' and '"'"' can be used to produce a literal single
quote. I'm not touching any of those here.
In t9401, tuck the redirecting ">" to the filename while we're touching
those lines.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-07 04:08:53 +08:00
|
|
|
test_i18ngrep "[Uu]sage:" msg
|
2010-06-14 13:32:09 +08:00
|
|
|
'
|
|
|
|
|
2023-04-30 18:00:34 +08:00
|
|
|
# the following two test cherry-pick and revert with renames
|
|
|
|
#
|
|
|
|
# --
|
|
|
|
# + rename2: renames oops to opos
|
|
|
|
# + rename1: renames oops to spoo
|
|
|
|
# + added: adds extra line to oops
|
|
|
|
# ++ initial: has lines in oops
|
|
|
|
|
2007-01-15 14:00:02 +08:00
|
|
|
test_expect_success 'cherry-pick after renaming branch' '
|
|
|
|
|
|
|
|
git checkout rename2 &&
|
2007-11-02 23:33:07 +08:00
|
|
|
git cherry-pick added &&
|
2022-04-05 21:47:42 +08:00
|
|
|
test_cmp_rev rename2 HEAD^ &&
|
2010-06-13 00:05:12 +08:00
|
|
|
grep "Add extra line at the end" opos &&
|
|
|
|
git reflog -1 | grep cherry-pick
|
2007-01-15 14:00:02 +08:00
|
|
|
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'revert after renaming branch' '
|
|
|
|
|
|
|
|
git checkout rename1 &&
|
2007-11-02 23:33:07 +08:00
|
|
|
git revert added &&
|
2022-04-05 21:47:42 +08:00
|
|
|
test_cmp_rev rename1 HEAD^ &&
|
|
|
|
test_path_is_file spoo &&
|
|
|
|
test_cmp_rev initial:oops HEAD:spoo &&
|
2010-06-13 00:05:12 +08:00
|
|
|
git reflog -1 | grep revert
|
2007-01-15 14:00:02 +08:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2010-11-01 03:59:33 +08:00
|
|
|
test_expect_success 'cherry-pick on stat-dirty working tree' '
|
|
|
|
git clone . copy &&
|
|
|
|
(
|
|
|
|
cd copy &&
|
|
|
|
git checkout initial &&
|
2018-03-24 15:44:31 +08:00
|
|
|
test-tool chmtime +40 oops &&
|
2010-11-01 03:59:33 +08:00
|
|
|
git cherry-pick added
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2011-04-13 07:23:01 +08:00
|
|
|
test_expect_success 'revert forbidden on dirty working tree' '
|
2008-03-03 14:30:56 +08:00
|
|
|
|
|
|
|
echo content >extra_file &&
|
|
|
|
git add extra_file &&
|
|
|
|
test_must_fail git revert HEAD 2>errors &&
|
2016-10-21 20:26:25 +08:00
|
|
|
test_i18ngrep "your local changes would be overwritten by " errors
|
2008-03-03 14:30:56 +08:00
|
|
|
|
|
|
|
'
|
|
|
|
|
2013-09-06 05:51:17 +08:00
|
|
|
test_expect_success 'cherry-pick on unborn branch' '
|
2012-12-22 03:10:11 +08:00
|
|
|
git checkout --orphan unborn &&
|
|
|
|
git rm --cached -r . &&
|
|
|
|
rm -rf * &&
|
|
|
|
git cherry-pick initial &&
|
|
|
|
git diff --quiet initial &&
|
2019-11-13 07:07:45 +08:00
|
|
|
test_cmp_rev ! initial HEAD
|
2012-12-22 03:10:11 +08:00
|
|
|
'
|
|
|
|
|
2013-09-05 22:57:23 +08:00
|
|
|
test_expect_success 'cherry-pick "-" to pick from previous branch' '
|
|
|
|
git checkout unborn &&
|
|
|
|
test_commit to-pick actual content &&
|
2020-11-19 07:44:26 +08:00
|
|
|
git checkout main &&
|
2013-09-05 22:57:23 +08:00
|
|
|
git cherry-pick - &&
|
|
|
|
echo content >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'cherry-pick "-" is meaningless without checkout' '
|
|
|
|
test_create_repo afresh &&
|
|
|
|
(
|
|
|
|
cd afresh &&
|
|
|
|
test_commit one &&
|
|
|
|
test_commit two &&
|
|
|
|
test_commit three &&
|
|
|
|
test_must_fail git cherry-pick -
|
|
|
|
)
|
|
|
|
'
|
|
|
|
|
2013-10-11 00:41:17 +08:00
|
|
|
test_expect_success 'cherry-pick "-" works with arguments' '
|
|
|
|
git checkout -b side-branch &&
|
|
|
|
test_commit change actual change &&
|
2020-11-19 07:44:26 +08:00
|
|
|
git checkout main &&
|
2013-10-11 00:41:17 +08:00
|
|
|
git cherry-pick -s - &&
|
|
|
|
echo "Signed-off-by: C O Mitter <committer@example.com>" >expect &&
|
|
|
|
git cat-file commit HEAD | grep ^Signed-off-by: >signoff &&
|
|
|
|
test_cmp expect signoff &&
|
|
|
|
echo change >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2018-04-20 01:58:18 +08:00
|
|
|
test_expect_success 'cherry-pick works with dirty renamed file' '
|
2016-11-26 20:48:02 +08:00
|
|
|
test_commit to-rename &&
|
|
|
|
git checkout -b unrelated &&
|
|
|
|
test_commit unrelated &&
|
|
|
|
git checkout @{-1} &&
|
|
|
|
git mv to-rename.t renamed &&
|
|
|
|
test_tick &&
|
|
|
|
git commit -m renamed &&
|
|
|
|
echo modified >renamed &&
|
2019-12-19 02:12:00 +08:00
|
|
|
git cherry-pick refs/heads/unrelated &&
|
merge-recursive: improve add_cacheinfo error handling
Four closely related changes all with the purpose of fixing error handling
in this function:
- fix reported function name in add_cacheinfo error messages
- differentiate between the two error messages
- abort early when we hit the error (stop ignoring return code)
- mark a test which was hitting this error as failing until we get the
right fix
In more detail...
In commit 0424138d5715 ("Fix bogus error message from merge-recursive
error path", 2007-04-01), it was noted that the name of the function which
the error message claimed it was reported from did not match the actual
function name. This was changed to something closer to the real function
name, but it still didn't match the actual function name. Fix the
reported name to match.
Second, the two errors in this function had identical messages, preventing
us from knowing which error had been triggered. Add a couple words to the
second error message to differentiate the two.
Next, make sure callers do not ignore the return code so that it will stop
processing further entries (processing further entries could result in
more output which could cause the error to scroll off the screen, or at
least be missed by the user) and make it clear the error is the cause of
the early abort. These errors should never be triggered in production; if
either one is, it represents a bug in the calling path somewhere and is
likely to have resulted in mis-merged content. The combination of
ignoring of the return code and continuing to print other standard
messages after hitting the error resulted in the following bug report from
Junio: "...the command pretends that everything went well and merged
cleanly in that path...[Behaving] in a buggy and unexplainable way is bad
enough, doing so silently is unexcusable." Fix this.
Finally, there was one test in the testsuite that did hit this error path,
but was passing anyway. This would have been easy to miss since it had a
test_must_fail and thus could have failed for the wrong reason, but in a
separate testing step I added an intentional NULL-dereference to the
codepath where these error messages are printed in order to flush out such
cases. I could modify that test to explicitly check for this error and
fail the test if it is hit, but since this test operates in a bit of a
gray area and needed other changes, I went for a different fix. The gray
area this test operates in is the following: If the merge of a certain
file results in the same version of the file that existed in HEAD, but
there are dirty modifications to the file, is that an error with a
"Refusing to overwrite existing file" expected, or a case where the merge
should succeed since we shouldn't have to touch the dirty file anyway?
Recent discussion on the list leaned towards saying it should be a
success. Therefore, change the expected behavior of this test to match.
As a side effect, this makes the failed-due-to-hitting-add_cacheinfo-error
very clear, and we can mark the test as test_expect_failure. A subsequent
commit will implement the necessary changes to get this test to pass
again.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-04-20 01:58:16 +08:00
|
|
|
test $(git rev-parse :0:renamed) = $(git rev-parse HEAD~2:to-rename.t) &&
|
2018-01-06 04:19:59 +08:00
|
|
|
grep -q "^modified$" renamed
|
2016-11-26 20:48:02 +08:00
|
|
|
'
|
|
|
|
|
cherry-pick: use better advice message
"git cherry-pick", upon seeing a conflict, says:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
as if running "git commit" to conclude the resolution of
this single step were the end of the story. This stems from
the fact that the command originally was to pick a single
commit and not a range of commits, and the message was
written back then and has not been adjusted.
When picking a range of commits and the command stops with a
conflict in the middle of the range, however, after
resolving the conflict and (optionally) recording the result
with "git commit", the user has to run "git cherry-pick
--continue" to have the rest of the range dealt with,
"--skip" to drop the current commit, or "--abort" to discard
the series.
Suggest use of "git cherry-pick --continue/--skip/--abort"
so that the message also covers the case where a range of
commits are being picked.
Similarly, this optimization can be applied to git revert,
suggest use of "git revert --continue/--skip/--abort" so
that the message also covers the case where a range of
commits are being reverted.
It is worth mentioning that now we use advice() to print
the content of GIT_CHERRY_PICK_HELP in print_advice(), each
line of output will start with "hint: ".
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Hariom Verma <hariom18599@gmail.com>
Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-22 21:08:41 +08:00
|
|
|
test_expect_success 'advice from failed revert' '
|
revert: optionally refer to commit in the "reference" format
A typical "git revert" commit uses the full title of the original
commit in its title, and starts its body of the message with:
This reverts commit 8fa7f667cf61386257c00d6e954855cc3215ae91.
This does not encourage the best practice of describing not just
"what" (i.e. "Revert X" on the title says what we did) but "why"
(i.e. and it does not say why X was undesirable).
We can instead phrase this first line of the body to be more like
This reverts commit 8fa7f667 (do this and that, 2022-04-25)
so that the title does not have to be
Revert "do this and that"
We can instead use the title to describe "why" we are reverting the
original commit.
Introduce the "--reference" option to "git revert", and also the
revert.reference configuration variable, which defaults to false, to
tweak the title and the first line of the draft commit message for
when creating a "revert" commit.
When this option is in use, the first line of the pre-filled editor
buffer becomes a comment line that tells the user to say _why_. If
the user exits the editor without touching this line by mistake,
what we prepare to become the first line of the body, i.e. "This
reverts commit 8fa7f667 (do this and that, 2022-04-25)", ends up to
be the title of the resulting commit. This behaviour is designed to
help such a user to identify such a revert in "git log --oneline"
easily so that it can be further reworded with "git rebase -i" later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-27 14:01:39 +08:00
|
|
|
test_when_finished "git reset --hard" &&
|
cherry-pick: use better advice message
"git cherry-pick", upon seeing a conflict, says:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
as if running "git commit" to conclude the resolution of
this single step were the end of the story. This stems from
the fact that the command originally was to pick a single
commit and not a range of commits, and the message was
written back then and has not been adjusted.
When picking a range of commits and the command stops with a
conflict in the middle of the range, however, after
resolving the conflict and (optionally) recording the result
with "git commit", the user has to run "git cherry-pick
--continue" to have the rest of the range dealt with,
"--skip" to drop the current commit, or "--abort" to discard
the series.
Suggest use of "git cherry-pick --continue/--skip/--abort"
so that the message also covers the case where a range of
commits are being picked.
Similarly, this optimization can be applied to git revert,
suggest use of "git revert --continue/--skip/--abort" so
that the message also covers the case where a range of
commits are being reverted.
It is worth mentioning that now we use advice() to print
the content of GIT_CHERRY_PICK_HELP in print_advice(), each
line of output will start with "hint: ".
Mentored-by: Christian Couder <christian.couder@gmail.com>
Mentored-by: Hariom Verma <hariom18599@gmail.com>
Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: ZheNing Hu <adlternative@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-22 21:08:41 +08:00
|
|
|
test_commit --no-tag "add dream" dream dream &&
|
|
|
|
dream_oid=$(git rev-parse --short HEAD) &&
|
|
|
|
cat <<-EOF >expected &&
|
|
|
|
error: could not revert $dream_oid... add dream
|
|
|
|
hint: After resolving the conflicts, mark them with
|
|
|
|
hint: "git add/rm <pathspec>", then run
|
|
|
|
hint: "git revert --continue".
|
|
|
|
hint: You can instead skip this commit with "git revert --skip".
|
|
|
|
hint: To abort and get back to the state before "git revert",
|
|
|
|
hint: run "git revert --abort".
|
|
|
|
EOF
|
|
|
|
test_commit --append --no-tag "double-add dream" dream dream &&
|
|
|
|
test_must_fail git revert HEAD^ 2>actual &&
|
|
|
|
test_cmp expected actual
|
|
|
|
'
|
revert: optionally refer to commit in the "reference" format
A typical "git revert" commit uses the full title of the original
commit in its title, and starts its body of the message with:
This reverts commit 8fa7f667cf61386257c00d6e954855cc3215ae91.
This does not encourage the best practice of describing not just
"what" (i.e. "Revert X" on the title says what we did) but "why"
(i.e. and it does not say why X was undesirable).
We can instead phrase this first line of the body to be more like
This reverts commit 8fa7f667 (do this and that, 2022-04-25)
so that the title does not have to be
Revert "do this and that"
We can instead use the title to describe "why" we are reverting the
original commit.
Introduce the "--reference" option to "git revert", and also the
revert.reference configuration variable, which defaults to false, to
tweak the title and the first line of the draft commit message for
when creating a "revert" commit.
When this option is in use, the first line of the pre-filled editor
buffer becomes a comment line that tells the user to say _why_. If
the user exits the editor without touching this line by mistake,
what we prepare to become the first line of the body, i.e. "This
reverts commit 8fa7f667 (do this and that, 2022-04-25)", ends up to
be the title of the resulting commit. This behaviour is designed to
help such a user to identify such a revert in "git log --oneline"
easily so that it can be further reworded with "git rebase -i" later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2022-05-27 14:01:39 +08:00
|
|
|
|
|
|
|
test_expect_success 'identification of reverted commit (default)' '
|
|
|
|
test_commit to-ident &&
|
|
|
|
test_when_finished "git reset --hard to-ident" &&
|
|
|
|
git checkout --detach to-ident &&
|
|
|
|
git revert --no-edit HEAD &&
|
|
|
|
git cat-file commit HEAD >actual.raw &&
|
|
|
|
grep "^This reverts " actual.raw >actual &&
|
|
|
|
echo "This reverts commit $(git rev-parse HEAD^)." >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'identification of reverted commit (--reference)' '
|
|
|
|
git checkout --detach to-ident &&
|
|
|
|
git revert --reference --no-edit HEAD &&
|
|
|
|
git cat-file commit HEAD >actual.raw &&
|
|
|
|
grep "^This reverts " actual.raw >actual &&
|
|
|
|
echo "This reverts commit $(git show -s --pretty=reference HEAD^)." >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'identification of reverted commit (revert.reference)' '
|
|
|
|
git checkout --detach to-ident &&
|
|
|
|
git -c revert.reference=true revert --no-edit HEAD &&
|
|
|
|
git cat-file commit HEAD >actual.raw &&
|
|
|
|
grep "^This reverts " actual.raw >actual &&
|
|
|
|
echo "This reverts commit $(git show -s --pretty=reference HEAD^)." >expect &&
|
|
|
|
test_cmp expect actual
|
|
|
|
'
|
|
|
|
|
2022-06-01 00:22:20 +08:00
|
|
|
test_expect_success 'cherry-pick is unaware of --reference (for now)' '
|
|
|
|
test_when_finished "git reset --hard" &&
|
|
|
|
test_must_fail git cherry-pick --reference HEAD 2>actual &&
|
|
|
|
grep "^usage: git cherry-pick" actual
|
|
|
|
'
|
|
|
|
|
2007-01-15 14:00:02 +08:00
|
|
|
test_done
|