git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pete Harlan <pgit@pcharlan.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [bug?] checkout -m doesn't work without a base version
Date: Tue, 06 Dec 2011 23:30:57 -0800	[thread overview]
Message-ID: <4EDF1631.5090906@pcharlan.com> (raw)
In-Reply-To: <7vbormn8vk.fsf@alter.siamese.dyndns.org>

On 12/05/2011 10:58 AM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
> 
>> But this only works if there's a base version; if foo.c was added in
>> each branch, we get:
>>
>>    error: path 'foo.c' does not have all three versions
>>
>> Git didn't need all three versions to create the original conflicted
>> file, so why would it need them to recreate it?
> 
> Because the original "merge" was a bit more carefully written but
> "checkout -m" was written without worrying too much about "both sides
> added differently" corner case and still being defensive about not doing
> random thing upon getting an unexpected input state.
> 
> IOW, being lazy ;-)
> 
> How does this look?

Wow, thanks for the quick response! That does indeed let me checkout
the file as expected.

I wrote a test (below) to be folded in with your patch, but the test
fails because it expects the restored file to be the same as the
originally-conflicted file, but the conflict-line labels change from
"HEAD" and "master":

  <<<<<<< HEAD
  in_topic
  =======
  in_master
  >>>>>>> master

to "ours" and "theirs".  (The same thing happens in the 3-way merge
case.)

If the label change is expected then I can rewrite the test to ignore
labels, or to expect "ours" and "theirs", whichever you think is best.
If the label change is unexpected, then I guess the test is good :)

--Pete

-- >8 --
Test 'checkout -m -- path' when path is a 2-way merge

Signed-off-by: Pete Harlan <pgit@pcharlan.com>
---
 t/t2023-checkout-m-twoway.sh |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)
 create mode 100755 t/t2023-checkout-m-twoway.sh

diff --git a/t/t2023-checkout-m-twoway.sh b/t/t2023-checkout-m-twoway.sh
new file mode 100755
index 0000000..5b50360
--- /dev/null
+++ b/t/t2023-checkout-m-twoway.sh
@@ -0,0 +1,29 @@
+#!/bin/sh
+
+test_description='checkout -m -- conflicted/path/with/2-way/merge
+
+Ensures that checkout -m on a resolved file restores the conflicted file
+when it conflicted with a 2-way merge.'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+	test_tick &&
+	test_commit initial_commit &&
+	git branch topic &&
+	test_commit added_in_master file.txt in_master &&
+	git checkout topic &&
+	test_commit added_in_topic file.txt in_topic
+'
+
+test_must_fail git merge master
+
+test_expect_success '-m restores 2-way conflicted+resolved file' '
+	cp file.txt file.txt.conflicted &&
+	echo resolved >file.txt &&
+	git add file.txt &&
+	git checkout -m -- file.txt &&
+	test_cmp file.txt.conflicted file.txt
+'
+
+test_done

  reply	other threads:[~2011-12-07  7:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-04 22:31 [bug?] checkout -m doesn't work without a base version Pete Harlan
2011-12-05 18:58 ` Junio C Hamano
2011-12-07  7:30   ` Pete Harlan [this message]
2011-12-08 18:27     ` Junio C Hamano
2011-12-12  1:48       ` Pete Harlan
2011-12-12  5:29         ` Junio C Hamano
2011-12-20 20:37     ` [PATCH] t/t2023-checkout-m.sh: fix use of test_must_fail Ævar Arnfjörð Bjarmason
2011-12-20 21:23       ` Junio C Hamano
2011-12-14 10:19   ` [bug?] checkout -m doesn't work without a base version Michael Schubert
2011-12-14 17:54     ` Junio C Hamano
2011-12-15  4:20       ` Miles Bader
2011-12-15 10:11         ` Michael Schubert
2011-12-15 10:42       ` Andreas Schwab
2011-12-15 17:36         ` Junio C Hamano
2011-12-16 22:38           ` Ramsay Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EDF1631.5090906@pcharlan.com \
    --to=pgit@pcharlan.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).