How to selectively recreate merge state?

How to selectively recreate merge state?

[Jay Soffian]

Let's say you initiate a merge:

$ git merge topic

And this merge results in conflicts in two files, foo and bar. You
resolve the conflicts in both files, but then decide you don't like
how you resolved bar.

How do you set the index and working-copy back to the state it was
immediately after doing the merge for bar, while leaving the merge
resolution alone for foo?

j.

Re: How to selectively recreate merge state?

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> Let's say you initiate a merge:
>
> $ git merge topic
>
> And this merge results in conflicts in two files, foo and bar. You
> resolve the conflicts in both files, but then decide you don't like
> how you resolved bar.
>
> How do you set the index and working-copy back to the state it was
> immediately after doing the merge for bar, while leaving the merge
> resolution alone for foo?

Before you "git add bar", you can say "git checkout --conflict=merge bar"
(or --conflict=diff3).

After "git add bar", you can't.  Save what you have resolved so far in a
separate file (e.g. "cp foo foo.resolved"), reset to the previous state
and redo the merge.

Re: How to selectively recreate merge state?

[Jakub Narebski]

Junio C Hamano <gitster@pobox.com> writes:

> Jay Soffian <jaysoffian@gmail.com> writes:
> 
> > Let's say you initiate a merge:
> >
> > $ git merge topic
> >
> > And this merge results in conflicts in two files, foo and bar. You
> > resolve the conflicts in both files, but then decide you don't like
> > how you resolved bar.
> >
> > How do you set the index and working-copy back to the state it was
> > immediately after doing the merge for bar, while leaving the merge
> > resolution alone for foo?
> 
> Before you "git add bar", you can say "git checkout --conflict=merge bar"
> (or --conflict=diff3).

Or (if I understand manpage correctly) just "git checkout --conflict bar".
 
> After "git add bar", you can't.  Save what you have resolved so far in a
> separate file (e.g. "cp foo foo.resolved"), reset to the previous state
> and redo the merge.

Hmmm... isn't it what "git update-index --unresolve bar" is for?

  --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...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: How to selectively recreate merge state?

[Junio C Hamano]

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.

Re: How to selectively recreate merge state?

[Jakub Narebski]

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

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)?


 $ 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

-- 
Jakub Narebski
Poland

Re: How to selectively recreate merge state?

[Michael J Gruber]

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
> 
> 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.

> 
>  $ 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...

Re: How to selectively recreate merge state?

[Björn Steinbrink]

On 2009.12.11 11:44:25 +0100, Michael J Gruber wrote:
> Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> >  $ 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...

Hm, isn't that "$(git merge-base HEAD MERGE_HEAD):foo"?

Björn

Re: How to selectively recreate merge state?

[Jakub Narebski]

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.

>> 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.

>> 
>>  $ 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"

-- 
Jakub Narebski
Poland

Re: How to selectively recreate merge state?

[Michael J Gruber]

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

Re: How to selectively recreate merge state?

[Thomas Rast]

Björn Steinbrink wrote:
> On 2009.12.11 11:44:25 +0100, Michael J Gruber wrote:
> > Jakub Narebski venit, vidit, dixit 11.12.2009 02:33:
> > >  $ echo -e "100644 257cc5642cb1a054f08cc83f2d943e56fd3ebe99 1\tfoo" | 
> > >    git update-index --index-info
> > 
> > Yeah, if we knew that sha1...
> 
> Hm, isn't that "$(git merge-base HEAD MERGE_HEAD):foo"?

Not if the merge-base isn't unique and you're using the recursive
strategy, IIUC.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: How to selectively recreate merge state?

[Jakub Narebski]

Dnia piątek 11. grudnia 2009 13:33, Michael J Gruber napisał:
> 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?

I have thought that if there exist stage #0 in index, git simply _ignores_
higher stages, so git-add simply adds stage #0 and does not delete higher
stages.

But I see that "git update-index --unresolve" (and its predecessor 
"git-unresolve") simply recreate stages #2 and #3.


The documentation of "git update-index --unresolve" lacks this info,
and it doesn't tell one what it is for (see commit message for commit
ec16779 (Add git-unresolve <paths>..., 2006-04-19)).

-- 
Jakub Narebski
Poland

Re: How to selectively recreate merge state?

[Michael J Gruber]

Jakub Narebski venit, vidit, dixit 11.12.2009 15:00:
> Dnia piątek 11. grudnia 2009 13:33, Michael J Gruber napisał:
>> 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?
> 
> I have thought that if there exist stage #0 in index, git simply _ignores_
> higher stages, so git-add simply adds stage #0 and does not delete higher
> stages.
> 
> But I see that "git update-index --unresolve" (and its predecessor 
> "git-unresolve") simply recreate stages #2 and #3.
> 
> 
> The documentation of "git update-index --unresolve" lacks this info,
> and it doesn't tell one what it is for (see commit message for commit
> ec16779 (Add git-unresolve <paths>..., 2006-04-19)).
> 

Oh yes, one should always read the classics ;) [Really nice commit
message, that is.]

Michael

Re: How to selectively recreate merge state?

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

>> The documentation of "git update-index --unresolve" lacks this info,
>> and it doesn't tell one what it is for (see commit message for commit
>> ec16779 (Add git-unresolve <paths>..., 2006-04-19)).
>
> Oh yes, one should always read the classics ;) [Really nice commit
> message, that is.]

Thanks.

This is exactly why I often give _explanation_ of the current behaviour
based on history, without defending it is good nor claiming it is bad.
Knowing how things came about gives us better perspective to decide where
to go next.

Re: How to selectively recreate merge state?

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> I have thought that if there exist stage #0 in index, git simply _ignores_
> higher stages, so git-add simply adds stage #0 and does not delete higher
> stages.

Then you thought wrong ;-).

Leaving resolved cruft in the main index (aka active_cache[]) will make
all the normal operation codepath unnecessarily complex.  They rely on "if
I see stage #0, there is no higher stages for the same path".  And extra
checks will slow things down.

But that does not necessarily mean the index is a wrong place to save away
pre-resolution information on resolved paths (read on).

Before suggesting a possible next move, there are a few things we should
notice while reading ec16779 (Add git-unresolve <paths>..., 2006-04-19):

 - This was done about only one year after git was born.  You should not
   take it granted that the workflow it wanted to support makes sense.

   Considering that using "git add" to mark the resolution is to declare
   that you are _finished_ with that path, using it for other purposes
   (e.g. leaving a note that says "I've looked at and have one possible
   resolution in the file in the work tree, but I haven't verified the
   result yet", which is what the commit talks about) is simply an
   (ab|mis)use of the index.  Lossage of higher stage information by this
   misuse is user's problem, and there is this thing called pen & pencil
   the user can use for taking notes if s/he does not want to lose the
   original conflict information from the index.

 - Even if we for a moment consider that the workflow made some sense, the
   particular implementation is not suitable anymore for today's git.

   Again, this was done only one year after git was born, and back then
   "pull/merge" were the only things that left conflicts in every day
   operations by end users, and not many people didn't expect git to merge
   across renames.  It was sufficient to read the path the end user asked
   for from HEAD and MERGE_HEAD and pretend we "unresolved" in such a
   simpler world.

   But "merge" is not the primary thing that gives you conflicts anymore.
   "rebase", "cherry-pick", "stash apply" are much more widely used by
   ordinary users these days than back then, and reading from MERGE_HEAD
   wouldn't do any good for recreating what these operations did.  Even
   with "merge", stages #2 and #3 can come from a totally different path
   when using recursive and subtree strategies, so reading from
   HEAD/MERGE_HEAD is not as useful as it used to be.

In fact, considering that there are many ways conflicts can be left in the
index and there are only two ways that they are resolved in the index by
the user (and both eventually uses a single function to do so), it would
make perfect sense to do the following:

 - Define a new index extension section to record "unresolve"
   information.

 - Every time add_index_entry_with_check() in read-cache.c records a stage
   0 entry while dropping higher stage entries for the same path, record
   these higher stage entries to the "unresolve" section.

 - An "update-index --unresolve" will use the information from this
   "unresolve" extension to recreate the unmerged state.

 - "rerere forget" that we earlier talked about in a separate thread will
   use exactly the same mechanism to get back the unmerged state to
   recompute the conflict identifier (this is why J6t is addded to the Cc:
   list).

 - "checkout --conflict" _might_ want to also consider unresolving the
   path first using this information, if it finds the path user asked to
   re-checkout with conflict markers has already been resolved.

It is important to think through to decide when we purge the "unresolve"
section.

If you run "read-tree", "checkout" to switch branches, or "reset" (any
option other than "--soft" which does not even touch the index), it is a
good sign that the information in the "unresolve" extension section is no
longer needed, so you can drop the section in these operations.

Optionally, write_index() could notice if there is no unmerged entries and
the cache_tree is fully valid---that is an indication that a tree object
has been written out of the now resolved index, and may (or may not) imply
that the "unresolve" information is no longer needed.  But I haven't
thought this last one through.  You could wish to unresolve even after you
committed your merge (you _could_ wish for anything after all), but I do
not yet know if granting that wish makes much sense.

There may be other cases we _must_ drop "unresolve".

Re: How to selectively recreate merge state?

[Paolo Bonzini]

On 12/11/2009 12:20 PM, Jakub Narebski wrote:
>> >  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.

Only "next to".  It can still be useful if you added a file before 
editing it, so you left in the conflict markers.

Paolo

Re: How to selectively recreate merge state?

[Junio C Hamano]

Paolo Bonzini <bonzini@gnu.org> writes:

> On 12/11/2009 12:20 PM, Jakub Narebski wrote:
>>> >  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.
>
> Only "next to".  It can still be useful if you added a file before
> editing it, so you left in the conflict markers.

To be fair, these need to be judged within their context, and then get
updated to today's reality.

"diff --cc" was merely a relatively new curiosity that allows a different
view into a conflicted merge (it was still cooking in 'next').  The
primary ways to inspect a conflict were "diff --theirs" and "diff --ours";
repopulating stages #2 and #3 was sufficient for them.

Re: How to selectively recreate merge state?

[Jay Soffian]

On Fri, Dec 11, 2009 at 2:24 PM, Junio C Hamano <gitster@pobox.com> wrote:
>  - This was done about only one year after git was born.  You should not
>   take it granted that the workflow it wanted to support makes sense.
>
>   Considering that using "git add" to mark the resolution is to declare
>   that you are _finished_ with that path, using it for other purposes
>   (e.g. leaving a note that says "I've looked at and have one possible
>   resolution in the file in the work tree, but I haven't verified the
>   result yet", which is what the commit talks about) is simply an
>   (ab|mis)use of the index.  Lossage of higher stage information by this
>   misuse is user's problem, and there is this thing called pen & pencil
>   the user can use for taking notes if s/he does not want to lose the
>   original conflict information from the index.

Just a little more data. What happened in my case was that I was using
a visual merge tool and accidentally saved instead of canceled, so git
mergetool automagically added my results. I had resolved about 15
files, and made a mistake with only one, so I was sad when I couldn't
determine how to unresolve that one file (at which point I saved off
the other 14 resolutions, reset, re-did the merge).

My intuition led me to try "git reset <path>" since that's how one
normally unstages additions to the index. But of course that didn't
work, where "of course" only makes sense if you know how the index is
used during a merge.

> In fact, considering that there are many ways conflicts can be left in the
> index and there are only two ways that they are resolved in the index by
> the user (and both eventually uses a single function to do so), it would
> make perfect sense to do the following:
>
> [...excellent list of suggestions elided...]

Also, I think we could improve the output of "git status" during merge
resolution, both before and after conflicts have been resolved in a
file. Immediately after a conflict, the conflicted files are shown as
"unmerged":

$ git status
foo: needs merge
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#	unmerged:   foo
#
no changes added to commit (use "git add" and/or "git commit -a")

"unmerged" is good. But the instruction to use "git checkout --
<file>" to discard changes is wrong in this context:

$ git checkout -- foo
error: path 'foo' is unmerged

Then, after resolving foo and adding it:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   foo
#

Well, yes, I can use git reset, but that just keeps my side of the merge.

So I think with your suggested changes to the index, we can do better
with the status output during a merge.

j.

Re: How to selectively recreate merge state?

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> Also, I think we could improve the output of "git status" during merge
> resolution, both before and after conflicts have been resolved in a
> file.

I think you are talking about something that is largely unrelated, even
though they would be a pair of good issues to discuss.  The solution to
them does not have much to do with what we have been discussing so far in
this thread, and actually should be much simpler, which is a good news
;-).

> $ git status
> foo: needs merge
> # On branch master
> # Changed but not updated:
> #   (use "git add <file>..." to update what will be committed)
> #   (use "git checkout -- <file>..." to discard changes in working directory)
> #
> #	unmerged:   foo
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> "unmerged" is good. But the instruction to use "git checkout --
> <file>" to discard changes is wrong in this context:

You should be able to change this without any "unresolve" index extension
added to the index.  Just notice an unmerged entry in the index and reword
the message accordingly.

More importantly, note that "git status" lists "unmerged" entries in a
separate section in its output in 1.6.6 (and has been so on 'master' for
some time) and your problem report needs to be adjusted for a more recent
reality.  Here is what you would get:

        $ git status
        # On branch pu
        # Changes to be committed:
        #   (use "git reset HEAD <file>..." to unstage)
        #
        #       modified:   builtin-send-pack.c
        #       modified:   remote.c
        #       modified:   remote.h
        #       modified:   transport.c
        #
        # Unmerged paths:
        #   (use "git reset HEAD <file>..." to unstage)
        #   (use "git add <file>..." to mark resolution)
        #
        #       both modified:      transport-helper.c
        #

One problem we can see is that 'use "git reset HEAD <file>..." to unstage'
is an invalid advice if we are in the middle of a merge, but is perfectly
valid if this were during "rebase", "am -3", "cherry-pick" and "revert".

The solution to this issue is exactly the same as the next one.

> $ git status
> # On branch master
> # Changes to be committed:
> #   (use "git reset HEAD <file>..." to unstage)
> #
> #	modified:   foo
> #
>
> Well, yes, I can use git reset, but that just keeps my side of the merge.

If the conflict was coming from "rebase", "cherry-pick", etc., there is
nothing but one side, as there is no merge going on, and what "git reset"
does is exactly what the message tells you---to unstage.

I think "git status" should notice that the next commit you would make
from this state will be a merge commit, and remove these "reset HEAD"
lines.  Once you "git add" to resolve, it makes _no_ sense to reset to
HEAD, if you are concluding a merge.  Until "update-index --unresolve" is
revived as a modern version (and I suspect that a more logical Porcelain
interface would be a new option "reset --unmerge <paths>..."), we should
simply drop "reset HEAD" advice when we are in a merge.

Note that the "unresolve" index extension will not help you at all in
order for you to decide if you are going to make a merge commit.  You
should instead ask "does .git/MERGE_HEAD exist?", and it is something you
should be able to implement directly on top of upcoming 1.6.6 release.

[PATCH 0/3] Update advice in commit/status output

[Junio C Hamano]

Jay Soffian noticed that we give "git reset HEAD <path>" as an instruction
to get rid of the local change that has already been added to the index
even when <path> is unmerged, or it is merged and we are about to commit a
merge.

In neither case, "git reset HEAD <path>" is absolutely a wrong thing to do
while merging.

This miniseries updates the advices given in status/commit.  It applies on
top of the jk/1.7.0-status topic, and has trivial conflicts in wt-status.c
with the jk/unwanted-advices topic that has already graduated to 'maint'.

Junio C Hamano (3):
  commit/status: check $GIT_DIR/MERGE_HEAD only once
  commit/status: "git add <path>" is not necessarily how to resolve
  status/commit: do not suggest "reset HEAD <path>" while merging

 builtin-commit.c    |   12 ++++++------
 t/t7060-wtstatus.sh |    3 +--
 wt-status.c         |   16 +++++++++++-----
 wt-status.h         |    1 +
 4 files changed, 19 insertions(+), 13 deletions(-)

[PATCH 1/3] commit/status: check $GIT_DIR/MERGE_HEAD only once

[Junio C Hamano]

The code checked for the MERGE_HEAD file to see if we were about
to commit a merge twice in the codepath; also one of them used a
variable merge_head_sha1[] which was set but was never used.

Just check it once, but do so also in "git status", too, as
we will be using this for status generation in the next patch.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 builtin-commit.c |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index b39295f..17dd462 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -36,7 +36,7 @@ static const char * const builtin_status_usage[] = {
 	NULL
 };
 
-static unsigned char head_sha1[20], merge_head_sha1[20];
+static unsigned char head_sha1[20];
 static char *use_message_buffer;
 static const char commit_editmsg[] = "COMMIT_EDITMSG";
 static struct lock_file index_lock; /* real index */
@@ -319,7 +319,7 @@ static char *prepare_index(int argc, const char **argv, const char *prefix, int
 	 */
 	commit_style = COMMIT_PARTIAL;
 
-	if (file_exists(git_path("MERGE_HEAD")))
+	if (in_merge)
 		die("cannot do a partial commit during a merge.");
 
 	memset(&partial, 0, sizeof(partial));
@@ -758,9 +758,6 @@ static int parse_and_validate_options(int argc, const char *argv[],
 	if (get_sha1("HEAD", head_sha1))
 		initial_commit = 1;
 
-	if (!get_sha1("MERGE_HEAD", merge_head_sha1))
-		in_merge = 1;
-
 	/* Sanity check options */
 	if (amend && initial_commit)
 		die("You have nothing to amend.");
@@ -951,6 +948,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 
 	wt_status_prepare(&s);
 	git_config(git_status_config, &s);
+	in_merge = file_exists(git_path("MERGE_HEAD"));
 	argc = parse_options(argc, argv, prefix,
 			     builtin_status_options,
 			     builtin_status_usage, 0);
@@ -1057,10 +1055,10 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 
 	wt_status_prepare(&s);
 	git_config(git_commit_config, &s);
+	in_merge = file_exists(git_path("MERGE_HEAD"));
 
 	if (s.use_color == -1)
 		s.use_color = git_use_color_default;
-
 	argc = parse_and_validate_options(argc, argv, builtin_commit_usage,
 					  prefix, &s);
 	if (dry_run) {
-- 
1.6.6.rc2.5.g49666

[PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve

[Junio C Hamano]

When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use.  Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 t/t7060-wtstatus.sh |    2 +-
 wt-status.c         |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index 7b5db80..6c1af26 100755
--- a/t/t7060-wtstatus.sh
+++ b/t/t7060-wtstatus.sh
@@ -32,7 +32,7 @@ cat >expect <<EOF
 # On branch side
 # Unmerged paths:
 #   (use "git reset HEAD <file>..." to unstage)
-#   (use "git add <file>..." to mark resolution)
+#   (use "git add/rm <file>..." as appropriately to mark resolution)
 #
 #	deleted by us:      foo
 #
diff --git a/wt-status.c b/wt-status.c
index 3fdcf97..5271b6a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -52,7 +52,7 @@ static void wt_status_print_unmerged_header(struct wt_status *s)
 		color_fprintf_ln(s->fp, c, "#   (use \"git reset %s <file>...\" to unstage)", s->reference);
 	else
 		color_fprintf_ln(s->fp, c, "#   (use \"git rm --cached <file>...\" to unstage)");
-	color_fprintf_ln(s->fp, c, "#   (use \"git add <file>...\" to mark resolution)");
+	color_fprintf_ln(s->fp, c, "#   (use \"git add/rm <file>...\" as appropriately to mark resolution)");
 	color_fprintf_ln(s->fp, c, "#");
 }
 
-- 
1.6.6.rc2.5.g49666

[PATCH 3/3] status/commit: do not suggest "reset HEAD <path>" while merging

[Junio C Hamano]

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>
---
 builtin-commit.c    |    2 ++
 t/t7060-wtstatus.sh |    1 -
 wt-status.c         |   14 ++++++++++----
 wt-status.h         |    1 +
 4 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/builtin-commit.c b/builtin-commit.c
index 17dd462..7218454 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -960,6 +960,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)
 	read_cache();
 	refresh_cache(REFRESH_QUIET|REFRESH_UNMERGED);
 	s.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;
+	s.in_merge = in_merge;
 	wt_status_collect(&s);
 
 	if (s.relative_paths)
@@ -1056,6 +1057,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
 	wt_status_prepare(&s);
 	git_config(git_commit_config, &s);
 	in_merge = file_exists(git_path("MERGE_HEAD"));
+	s.in_merge = in_merge;
 
 	if (s.use_color == -1)
 		s.use_color = git_use_color_default;
diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index 6c1af26..6dd7077 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 appropriately to mark resolution)
 #
 #	deleted by us:      foo
diff --git a/wt-status.c b/wt-status.c
index 5271b6a..3f62c44 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -47,8 +47,11 @@ void wt_status_prepare(struct wt_status *s)
 static void wt_status_print_unmerged_header(struct wt_status *s)
 {
 	const char *c = color(WT_STATUS_HEADER, s);
+
 	color_fprintf_ln(s->fp, c, "# Unmerged paths:");
-	if (!s->is_initial)
+	if (s->in_merge)
+		;
+	else if (!s->is_initial)
 		color_fprintf_ln(s->fp, c, "#   (use \"git reset %s <file>...\" to unstage)", s->reference);
 	else
 		color_fprintf_ln(s->fp, c, "#   (use \"git rm --cached <file>...\" to unstage)");
@@ -59,12 +62,14 @@ static void wt_status_print_unmerged_header(struct wt_status *s)
 static void wt_status_print_cached_header(struct wt_status *s)
 {
 	const char *c = color(WT_STATUS_HEADER, s);
+
 	color_fprintf_ln(s->fp, c, "# Changes to be committed:");
-	if (!s->is_initial) {
+	if (s->in_merge)
+		; /* NEEDSWORK: use "git reset --unresolve"??? */
+	else if (!s->is_initial)
 		color_fprintf_ln(s->fp, c, "#   (use \"git reset %s <file>...\" to unstage)", s->reference);
-	} else {
+	else
 		color_fprintf_ln(s->fp, c, "#   (use \"git rm --cached <file>...\" to unstage)");
-	}
 	color_fprintf_ln(s->fp, c, "#");
 }
 
@@ -72,6 +77,7 @@ static void wt_status_print_dirty_header(struct wt_status *s,
 					 int has_deleted)
 {
 	const char *c = color(WT_STATUS_HEADER, s);
+
 	color_fprintf_ln(s->fp, c, "# Changed but not updated:");
 	if (!has_deleted)
 		color_fprintf_ln(s->fp, c, "#   (use \"git add <file>...\" to update what will be committed)");
diff --git a/wt-status.h b/wt-status.h
index a4bddcf..c60f40a 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -34,6 +34,7 @@ struct wt_status {
 	const char **pathspec;
 	int verbose;
 	int amend;
+	int in_merge;
 	int nowarn;
 	int use_color;
 	int relative_paths;
-- 
1.6.6.rc2.5.g49666

Re: [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve

[Jeff King]

On Sat, Dec 12, 2009 at 01:02:02AM -0800, Junio C Hamano wrote:

> When the desired resolution is to remove the path, "git rm <path>" is the
> command the user needs to use.  Just like in "Changed but not updated"
> section, suggest to use "git add/rm" as appropriate.

I no longer even see these messages due to advice.statushints, but the
overall direction of the series looks sane to me.

However:

> -	color_fprintf_ln(s->fp, c, "#   (use \"git add <file>...\" to mark resolution)");
> +	color_fprintf_ln(s->fp, c, "#   (use \"git add/rm <file>...\" as appropriately to mark resolution)");

This should be "as appropriate".

-Peff

Re: [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve

[Nanako Shiraishi]

Quoting Junio C Hamano <gitster@pobox.com>

>  # On branch side
>  # Unmerged paths:
>  #   (use "git reset HEAD <file>..." to unstage)
> -#   (use "git add <file>..." to mark resolution)
> +#   (use "git add/rm <file>..." as appropriately to mark resolution)

Shouldn't this either be "as appropriate" or just "appropriately"?

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Sat, Dec 12, 2009 at 01:02:02AM -0800, Junio C Hamano wrote:
>
>> When the desired resolution is to remove the path, "git rm <path>" is the
>> command the user needs to use.  Just like in "Changed but not updated"
>> section, suggest to use "git add/rm" as appropriate.
>
> I no longer even see these messages due to advice.statushints, but the
> overall direction of the series looks sane to me.
>
> However:
>
>> -	color_fprintf_ln(s->fp, c, "#   (use \"git add <file>...\" to mark resolution)");
>> +	color_fprintf_ln(s->fp, c, "#   (use \"git add/rm <file>...\" as appropriately to mark resolution)");
>
> This should be "as appropriate".

Heh, I kant speel.  Fixed and re-pushed out on 'pu'.

Thanks.

Re: [PATCH 0/3] Update advice in commit/status output

[Sverre Rabbelier]

Heya,

On Sat, Dec 12, 2009 at 10:02, Junio C Hamano <gitster@pobox.com> wrote:
> In neither case, "git reset HEAD <path>" is absolutely a wrong thing to do
> while merging.

>From the patches I'm guessing you mean "In either case" instead?

-- 
Cheers,

Sverre Rabbelier

Re: [PATCH 0/3] Update advice in commit/status output

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

> Heya,
>
> On Sat, Dec 12, 2009 at 10:02, Junio C Hamano <gitster@pobox.com> wrote:
>> In neither case, "git reset HEAD <path>" is absolutely a wrong thing to do
>> while merging.
>
>>From the patches I'm guessing you mean "In either case" instead?

Correct.

Re: [PATCH 0/3] Update advice in commit/status output

[Jay Soffian]

On Sat, Dec 12, 2009 at 4:02 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian noticed that we give "git reset HEAD <path>" as an instruction
> to get rid of the local change that has already been added to the index
> even when <path> is unmerged, or it is merged and we are about to commit a
> merge.
>
> In neither case, "git reset HEAD <path>" is absolutely a wrong thing to do
> while merging.
>
> This miniseries updates the advices given in status/commit.  It applies on
> top of the jk/1.7.0-status topic, and has trivial conflicts in wt-status.c
> with the jk/unwanted-advices topic that has already graduated to 'maint'.

Series looks good to me after the spelling correction. Thank you.

j.