git/t/t3507-cherry-pick-conflict.sh

587 lines
15 KiB
Bash
Raw Normal View History

#!/bin/sh
test_description='test cherry-pick and revert with conflicts
-
+ picked: rewrites foo to c
+ base: rewrites foo to b
+ initial: writes foo as a, unrelated as unrelated
'
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
. ./test-lib.sh
pristine_detach () {
git checkout -f "$1^0" &&
git read-tree -u --reset HEAD &&
git clean -d -f -f -q -x
}
test_expect_success setup '
echo unrelated >unrelated &&
git add unrelated &&
test_commit initial foo a &&
test_commit base foo b &&
test_commit picked foo c &&
test_commit --signoff picked-signed foo d &&
git checkout -b topic initial &&
test_commit redundant-pick foo c redundant &&
git commit --allow-empty --allow-empty-message &&
git tag empty &&
git checkout main &&
git config advice.detachedhead false
'
test_expect_success 'failed cherry-pick does not advance HEAD' '
pristine_detach initial &&
head=$(git rev-parse HEAD) &&
test_must_fail git cherry-pick picked &&
newhead=$(git rev-parse HEAD) &&
test "$head" = "$newhead"
'
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 cherry-pick' '
pristine_detach initial &&
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
picked=$(git rev-parse --short picked) &&
cat <<-EOF >expected &&
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
error: could not apply $picked... picked
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".
EOF
test_must_fail git cherry-pick picked 2>actual &&
test_cmp expected actual
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 cherry-pick --no-commit' "
pristine_detach initial &&
picked=\$(git rev-parse --short picked) &&
cat <<-EOF >expected &&
error: could not apply \$picked... picked
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
EOF
test_must_fail git cherry-pick --no-commit picked 2>actual &&
test_cmp expected actual
"
test_expect_success 'failed cherry-pick sets CHERRY_PICK_HEAD' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
test_cmp_rev picked CHERRY_PICK_HEAD
'
test_expect_success 'successful cherry-pick does not set CHERRY_PICK_HEAD' '
pristine_detach initial &&
git cherry-pick base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success 'cherry-pick --no-commit does not set CHERRY_PICK_HEAD' '
pristine_detach initial &&
git cherry-pick --no-commit base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success 'cherry-pick w/dirty tree does not set CHERRY_PICK_HEAD' '
pristine_detach initial &&
echo foo >foo &&
test_must_fail git cherry-pick base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success \
'cherry-pick --strategy=resolve w/dirty tree does not set CHERRY_PICK_HEAD' '
pristine_detach initial &&
echo foo >foo &&
test_must_fail git cherry-pick --strategy=resolve base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success 'GIT_CHERRY_PICK_HELP suppresses CHERRY_PICK_HEAD' '
pristine_detach initial &&
(
GIT_CHERRY_PICK_HELP="and then do something else" &&
export GIT_CHERRY_PICK_HELP &&
test_must_fail git cherry-pick picked
) &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success 'git reset clears CHERRY_PICK_HEAD' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
git reset &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success 'failed commit does not clear CHERRY_PICK_HEAD' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
test_must_fail git commit &&
test_cmp_rev picked CHERRY_PICK_HEAD
'
test_expect_success 'cancelled commit does not clear CHERRY_PICK_HEAD' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
echo resolved >foo &&
git add foo &&
git update-index --refresh -q &&
test_must_fail git diff-index --exit-code HEAD &&
(
GIT_EDITOR=false &&
export GIT_EDITOR &&
test_must_fail git commit
) &&
test_cmp_rev picked CHERRY_PICK_HEAD
'
test_expect_success 'successful commit clears CHERRY_PICK_HEAD' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
echo resolved >foo &&
git add foo &&
git commit &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD
'
test_expect_success 'partial commit of cherry-pick fails' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
echo resolved >foo &&
git add foo &&
test_must_fail git commit foo 2>err &&
test_i18ngrep "cannot do a partial commit during a cherry-pick." err
'
test_expect_success 'commit --amend of cherry-pick fails' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
echo resolved >foo &&
git add foo &&
test_must_fail git commit --amend 2>err &&
test_i18ngrep "in the middle of a cherry-pick -- cannot amend." err
'
test_expect_success 'successful final commit clears cherry-pick state' '
pristine_detach initial &&
test_must_fail git cherry-pick base picked-signed &&
echo resolved >foo &&
test_path_is_file .git/sequencer/todo &&
git commit -a &&
test_path_is_missing .git/sequencer
'
test_expect_success 'reset after final pick clears cherry-pick state' '
pristine_detach initial &&
test_must_fail git cherry-pick base picked-signed &&
echo resolved >foo &&
test_path_is_file .git/sequencer/todo &&
git reset &&
test_path_is_missing .git/sequencer
'
test_expect_success 'failed cherry-pick produces dirty index' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
test_must_fail git update-index --refresh -q &&
test_must_fail git diff-index --exit-code HEAD
'
test_expect_success 'failed cherry-pick registers participants in index' '
pristine_detach initial &&
{
git checkout base -- foo &&
git ls-files --stage foo &&
git checkout initial -- foo &&
git ls-files --stage foo &&
git checkout picked -- foo &&
git ls-files --stage foo
} >stages &&
sed "
1 s/ 0 / 1 /
2 s/ 0 / 2 /
3 s/ 0 / 3 /
" stages >expected &&
git read-tree -u --reset HEAD &&
test_must_fail git cherry-pick picked &&
git ls-files --stage --unmerged >actual &&
test_cmp expected actual
'
test_expect_success \
'cherry-pick conflict, ensure commit.cleanup = scissors places scissors line properly' '
pristine_detach initial &&
git config commit.cleanup scissors &&
cat <<-EOF >expected &&
picked
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
#
# Conflicts:
# foo
EOF
test_must_fail git cherry-pick picked &&
test_cmp expected .git/MERGE_MSG
'
test_expect_success \
'cherry-pick conflict, ensure cleanup=scissors places scissors line properly' '
pristine_detach initial &&
git config --unset commit.cleanup &&
cat <<-EOF >expected &&
picked
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
#
# Conflicts:
# foo
EOF
test_must_fail git cherry-pick --cleanup=scissors picked &&
test_cmp expected .git/MERGE_MSG
'
test_expect_success 'failed cherry-pick describes conflict in work tree' '
pristine_detach initial &&
cat <<-EOF >expected &&
<<<<<<< HEAD
a
=======
c
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
>>>>>>> objid (picked)
EOF
test_must_fail git cherry-pick picked &&
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
sed "s/[a-f0-9]* (/objid (/" foo >actual &&
test_cmp expected actual
'
test_expect_success 'diff3 -m style' '
pristine_detach initial &&
git config merge.conflictstyle diff3 &&
cat <<-EOF >expected &&
<<<<<<< HEAD
a
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
||||||| parent of objid (picked)
b
=======
c
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
>>>>>>> objid (picked)
EOF
test_must_fail git cherry-pick picked &&
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
sed "s/[a-f0-9]* (/objid (/" foo >actual &&
test_cmp expected actual
'
test_expect_success 'revert also handles conflicts sanely' '
git config --unset merge.conflictstyle &&
pristine_detach initial &&
cat <<-EOF >expected &&
<<<<<<< HEAD
a
=======
b
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
>>>>>>> parent of objid (picked)
EOF
{
git checkout picked -- foo &&
git ls-files --stage foo &&
git checkout initial -- foo &&
git ls-files --stage foo &&
git checkout base -- foo &&
git ls-files --stage foo
} >stages &&
sed "
1 s/ 0 / 1 /
2 s/ 0 / 2 /
3 s/ 0 / 3 /
" stages >expected-stages &&
git read-tree -u --reset HEAD &&
head=$(git rev-parse HEAD) &&
test_must_fail git revert picked &&
newhead=$(git rev-parse HEAD) &&
git ls-files --stage --unmerged >actual-stages &&
test "$head" = "$newhead" &&
test_must_fail git update-index --refresh -q &&
test_must_fail git diff-index --exit-code HEAD &&
test_cmp expected-stages actual-stages &&
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
sed "s/[a-f0-9]* (/objid (/" foo >actual &&
test_cmp expected actual
'
test_expect_success 'failed revert sets REVERT_HEAD' '
pristine_detach initial &&
test_must_fail git revert picked &&
test_cmp_rev picked REVERT_HEAD
'
test_expect_success 'successful revert does not set REVERT_HEAD' '
pristine_detach base &&
git revert base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
test_must_fail git rev-parse --verify REVERT_HEAD
'
test_expect_success 'revert --no-commit sets REVERT_HEAD' '
pristine_detach base &&
git revert --no-commit base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
test_cmp_rev base REVERT_HEAD
'
test_expect_success 'revert w/dirty tree does not set REVERT_HEAD' '
pristine_detach base &&
echo foo >foo &&
test_must_fail git revert base &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
test_must_fail git rev-parse --verify REVERT_HEAD
'
test_expect_success 'GIT_CHERRY_PICK_HELP does not suppress REVERT_HEAD' '
pristine_detach initial &&
(
GIT_CHERRY_PICK_HELP="and then do something else" &&
GIT_REVERT_HELP="and then do something else, again" &&
export GIT_CHERRY_PICK_HELP GIT_REVERT_HELP &&
test_must_fail git revert picked
) &&
test_must_fail git rev-parse --verify CHERRY_PICK_HEAD &&
test_cmp_rev picked REVERT_HEAD
'
test_expect_success 'git reset clears REVERT_HEAD' '
pristine_detach initial &&
test_must_fail git revert picked &&
git reset &&
test_must_fail git rev-parse --verify REVERT_HEAD
'
test_expect_success 'failed commit does not clear REVERT_HEAD' '
pristine_detach initial &&
test_must_fail git revert picked &&
test_must_fail git commit &&
test_cmp_rev picked REVERT_HEAD
'
test_expect_success 'successful final commit clears revert state' '
pristine_detach picked-signed &&
test_must_fail git revert picked-signed base &&
echo resolved >foo &&
test_path_is_file .git/sequencer/todo &&
git commit -a &&
test_path_is_missing .git/sequencer
'
test_expect_success 'reset after final pick clears revert state' '
pristine_detach picked-signed &&
test_must_fail git revert picked-signed base &&
echo resolved >foo &&
test_path_is_file .git/sequencer/todo &&
git reset &&
test_path_is_missing .git/sequencer
'
test_expect_success 'revert conflict, diff3 -m style' '
pristine_detach initial &&
git config merge.conflictstyle diff3 &&
cat <<-EOF >expected &&
<<<<<<< HEAD
a
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
||||||| objid (picked)
c
=======
b
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
>>>>>>> parent of objid (picked)
EOF
test_must_fail git revert picked &&
sequencer: avoid garbled merge machinery messages due to commit labels sequencer's get_message() exists to provide good labels on conflict hunks; see commits d68565402a ("revert: clarify label on conflict hunks", 2010-03-20) bf975d379d ("cherry-pick, revert: add a label for ancestor", 2010-03-20) 043a4492b3 ("sequencer: factor code out of revert builtin", 2012-01-11). for background on this function. These labels are of the form <commitID>... <commit summary> or parent of <commitID>... <commit summary> These labels are then passed as branch names to the merge machinery. However, these labels, as formatted, often also serve to confuse. For example, if we have a rename involved in a content merge, then it results in text such as the following: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface... Removed unnecessary stuff:bar.c Or in various conflict messages, it can make it very difficult to read: CONFLICT (rename/delete): foo.c deleted in b01dface... Removed unnecessary stuff and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface... Removed unnecessary stuff inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Make a minor change to remove the ellipses and add parentheses around the commit summary; this makes all three examples much easier to read: <<<<<<<< HEAD:foo.c int j; ======== int counter; >>>>>>>> b01dface (Removed unnecessary stuff):bar.c CONFLICT (rename/delete): foo.c deleted in b01dface (Removed unnecessary stuff) and renamed in HEAD. Version HEAD of foo.c left in tree. CONFLICT (file location): dir1/foo.c added in b01dface (Removed unnecessary stuff) inside a directory that was renamed in HEAD, suggesting it should perhaps be moved to dir2/foo.c. Signed-off-by: Elijah Newren <newren@gmail.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-12 22:40:04 +08:00
sed "s/[a-f0-9]* (/objid (/" foo >actual &&
test_cmp expected actual
'
test_expect_success \
'revert conflict, ensure commit.cleanup = scissors places scissors line properly' '
pristine_detach initial &&
git config commit.cleanup scissors &&
cat >expected <<-EOF &&
Revert "picked"
This reverts commit OBJID.
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
#
# Conflicts:
# foo
EOF
test_must_fail git revert picked &&
sed "s/$OID_REGEX/OBJID/" .git/MERGE_MSG >actual &&
test_cmp expected actual
'
test_expect_success \
'revert conflict, ensure cleanup=scissors places scissors line properly' '
pristine_detach initial &&
git config --unset commit.cleanup &&
cat >expected <<-EOF &&
Revert "picked"
This reverts commit OBJID.
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
#
# Conflicts:
# foo
EOF
test_must_fail git revert --cleanup=scissors picked &&
sed "s/$OID_REGEX/OBJID/" .git/MERGE_MSG >actual &&
test_cmp expected actual
'
test_expect_success 'failed cherry-pick does not forget -s' '
pristine_detach initial &&
test_must_fail git cherry-pick -s picked &&
test_i18ngrep -e "Signed-off-by" .git/MERGE_MSG
'
test_expect_success 'commit after failed cherry-pick does not add duplicated -s' '
pristine_detach initial &&
test_must_fail git cherry-pick -s picked-signed &&
git commit -a -s &&
test $(git show -s >tmp && grep -c "Signed-off-by" tmp && rm tmp) = 1
'
test_expect_success 'commit after failed cherry-pick adds -s at the right place' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
git commit -a -s &&
# Do S-o-b and Conflicts appear in the right order?
cat <<-\EOF >expect &&
Signed-off-by: C O Mitter <committer@example.com>
# Conflicts:
EOF
grep -e "^# Conflicts:" -e "^Signed-off-by" .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual &&
cat <<-\EOF >expected &&
picked
Signed-off-by: C O Mitter <committer@example.com>
EOF
git show -s --pretty=format:%B >actual &&
test_cmp expected actual
'
test_expect_success 'commit --amend -s places the sign-off at the right place' '
pristine_detach initial &&
test_must_fail git cherry-pick picked &&
# emulate old-style conflicts block
mv .git/MERGE_MSG .git/MERGE_MSG+ &&
sed -e "/^# Conflicts:/,\$s/^# *//" .git/MERGE_MSG+ >.git/MERGE_MSG &&
git commit -a &&
git commit --amend -s &&
# Do S-o-b and Conflicts appear in the right order?
cat <<-\EOF >expect &&
Signed-off-by: C O Mitter <committer@example.com>
Conflicts:
EOF
grep -e "^Conflicts:" -e "^Signed-off-by" .git/COMMIT_EDITMSG >actual &&
test_cmp expect actual
'
test_expect_success 'cherry-pick preserves sparse-checkout' '
pristine_detach initial &&
test_config core.sparseCheckout true &&
test_when_finished "
echo \"/*\" >.git/info/sparse-checkout
git read-tree --reset -u HEAD
rm .git/info/sparse-checkout" &&
echo /unrelated >.git/info/sparse-checkout &&
git read-tree --reset -u HEAD &&
test_must_fail git cherry-pick -Xours picked>actual &&
test_i18ngrep ! "Changes not staged for commit:" actual
'
test_expect_success 'cherry-pick --continue remembers --keep-redundant-commits' '
test_when_finished "git cherry-pick --abort || :" &&
pristine_detach initial &&
test_must_fail git cherry-pick --keep-redundant-commits picked redundant &&
echo c >foo &&
git add foo &&
git cherry-pick --continue
'
test_expect_success 'cherry-pick --continue remembers --allow-empty and --allow-empty-message' '
test_when_finished "git cherry-pick --abort || :" &&
pristine_detach initial &&
test_must_fail git cherry-pick --allow-empty --allow-empty-message \
picked empty &&
echo c >foo &&
git add foo &&
git cherry-pick --continue
'
test_done