summaryrefslogtreecommitdiff
path: root/t
diff options
context:
space:
mode:
authorJunio C Hamano <gitster@pobox.com>2009-12-11 23:53:41 -0800
committerJunio C Hamano <gitster@pobox.com>2009-12-12 01:22:10 -0800
commit3c5884536563518ce6cd4dc782b0ebb670bf3b6d (patch)
tree2b6aa09fe2d8eb5e2f57e9517c327d0dd50b677a /t
parentdd20f8af1ae54773569b78b1b71d1ea663705d2c (diff)
downloadgit-3c5884536563518ce6cd4dc782b0ebb670bf3b6d.tar.gz
status/commit: do not suggest "reset HEAD <path>" while merging
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about to record a merge commit. For either an unmerged path (i.e. with unresolved conflicts), or an updated path, it would result in discarding what the other branch did. Note that we do not do anything special in a case where we are amending a merge. The user is making an evil merge starting from an already committed merge, and running "reset HEAD <path>" is the right way to get rid of the local edit that has been added to the index. Once "reset --unresolve <path>" becomes available, we might want to suggest it for a merged path that has unresolve information, but until then, just remove the incorrect advice. We might also want to suggest "checkout --conflict <path>" to revert the file in the work tree to the state of failed automerge for an unmerged path, but we never did that, and this commit does not change that. Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't')
-rwxr-xr-xt/t7060-wtstatus.sh1
1 files changed, 0 insertions, 1 deletions
diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index 0919ec46f6..fcac472598 100755
--- a/t/t7060-wtstatus.sh
+++ b/t/t7060-wtstatus.sh
@@ -31,7 +31,6 @@ test_expect_success 'Report new path with conflict' '
cat >expect <<EOF
# On branch side
# Unmerged paths:
-# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# deleted by us: foo