From: Michael J Gruber <git@drmicha•warpmail.net>
To: Jakub Narebski <jnareb@gmail•com>
Cc: Junio C Hamano <gitster@pobox•com>,
Jay Soffian <jaysoffian@gmail•com>, git <git@vger•kernel.org>
Subject: Re: How to selectively recreate merge state?
Date: Fri, 11 Dec 2009 13:33:34 +0100 [thread overview]
Message-ID: <4B223C1E.6010403@drmicha.warpmail.net> (raw)
In-Reply-To: <200912111220.40844.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 11.12.2009 12:20:
> Dnia piątek 11. grudnia 2009 11:44, Michael J Gruber napisał:
>> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
>>> Dnia piątek 11. grudnia 2009 02:11, Junio C Hamano napisał:
>>>> Jakub Narebski <jnareb@gmail•com> writes:
>>>>
>>>>> --unresolve::
>>>>> Restores the 'unmerged' or 'needs updating' state of a
>>>>> file during a merge if it was cleared by accident.
>>>>>
>>>>> Unless "git add foo" not only adds current contents of foo at stage 0,
>>>>> but also removes higher stages from index...
>>>>
>>>> By definition, adding anything at stage #0 is to remove higher stages.
>>>
>>> Hmmm... let's test it:
>>>
>>> $ git merge side-branch
>>> Auto-merging foo
>>> CONFLICT (content): Merge conflict in foo
>>> Automatic merge failed; fix conflicts and then commit the result.
>>> $ git ls-files --stage
>>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>> $ <edit foo>
>>> $ git add foo
>>> $ git ls-files --stage
>>> 100644 a1b58d38ffa61e8e99b7cb95cdf540aedf2a96b3 0 foo
>
> I thought that "git add foo" only adds current contents of foo in stage 0,
> and does not delete other stages.
>
> Unless "git add foo" does more than "git update-index foo" does here.
Quoting Junio:
By definition, adding anything at stage #0 is to remove higher stages.
Could one leave 1 alone but still mark the conflict resolved?
>>> Now let's test '--unresolve' option of git-update-index:
>>>
>>> $ git update-index --unresolve foo
>>> $ git ls-files --stage foo
>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>>
>>> WTF? What happened to stage 1 (ancestor)?
>>
>> 2 and 3 are easy (cheap) to recreate from HEAD and MERGE_HEAD, 1 is not.
>> I guess that's why --unresolve doesn't even attempt to do anything with 1.
>
> But then "git update-index --unresolve <file>" is next to useless.
Well, I'm not defending current behaviour, just describing its
implementation.
>
>>>
>>> $ git checkout --conflict=merge foo
>>> error: path 'foo' does not have all three versions
>>>
>>> Let's recover it by hand:
>>>
>>> $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" |
>>> git update-index --index-info
>>> $ git ls-files --stage foo
>>> 100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1 foo
>>> 100644 3bd1f0e29744a1f32b08d5650e62e2e62afb177c 2 foo
>>> 100644 469a41eda5c8b45503a3bfc32ad6b5decc658132 3 foo
>>> $ git checkout --conflict=merge foo
>>
>> Yeah, if we knew that sha1...
>
> Isn't it:
>
> $ git ls-tree $(git merge-base HEAD MERGE_HEAD) -- foo
>
> or
>
> $ git rev-parse "$(git merge-base HEAD MERGE_HEAD):foo"
Yes, sure. That's why I wrote "cheap": --unresolve simply reads HEAD and
MERGE_HEAD. Resetting 1 requires (re)calculation of the merge base.
Michael
next prev parent reply other threads:[~2009-12-11 12:35 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-10 23:56 How to selectively recreate merge state? Jay Soffian
2009-12-11 0:04 ` Junio C Hamano
2009-12-11 0:28 ` Jakub Narebski
2009-12-11 1:11 ` Junio C Hamano
2009-12-11 1:33 ` Jakub Narebski
2009-12-11 10:44 ` Michael J Gruber
2009-12-11 11:09 ` Björn Steinbrink
2009-12-11 12:51 ` Thomas Rast
2009-12-11 11:20 ` Jakub Narebski
2009-12-11 12:33 ` Michael J Gruber [this message]
2009-12-11 14:00 ` Jakub Narebski
2009-12-11 14:57 ` Michael J Gruber
2009-12-11 15:35 ` Junio C Hamano
2009-12-11 19:24 ` Junio C Hamano
2009-12-11 22:18 ` Jay Soffian
2009-12-11 23:46 ` Junio C Hamano
2009-12-12 9:02 ` [PATCH 0/3] Update advice in commit/status output Junio C Hamano
2009-12-12 9:02 ` [PATCH 1/3] commit/status: check $GIT_DIR/MERGE_HEAD only once Junio C Hamano
2009-12-12 9:02 ` [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve Junio C Hamano
2009-12-12 9:02 ` [PATCH 3/3] status/commit: do not suggest "reset HEAD <path>" while merging Junio C Hamano
2009-12-12 9:15 ` [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve Jeff King
2009-12-12 9:24 ` Junio C Hamano
2009-12-12 9:19 ` Nanako Shiraishi
2009-12-12 16:13 ` [PATCH 0/3] Update advice in commit/status output Sverre Rabbelier
2009-12-12 18:27 ` Junio C Hamano
2009-12-12 22:06 ` Jay Soffian
2009-12-11 20:38 ` How to selectively recreate merge state? Paolo Bonzini
2009-12-11 21:14 ` Junio C Hamano
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=4B223C1E.6010403@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=jaysoffian@gmail$(echo .)com \
--cc=jnareb@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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