threads / discuss / 21934
Subject: How to selectively recreate merge state?
Jay SoffianLet'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.
Junio C HamanoRe: How to selectively recreate merge state?
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.
Jakub NarebskiRe: How to selectively recreate merge state?
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
Junio C HamanoRe: How to selectively recreate merge state?
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.
Jakub NarebskiRe: How to selectively recreate merge state?
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
Michael J GruberRe: How to selectively recreate merge state?
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...
Björn SteinbrinkRe: How to selectively recreate merge state?
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
Thomas RastRe: How to selectively recreate merge state?
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.chJakub NarebskiRe: How to selectively recreate merge state?
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
Michael J GruberRe: How to selectively recreate merge state?
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
Jakub NarebskiRe: How to selectively recreate merge state?
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
Michael J GruberRe: How to selectively recreate merge state?
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
Junio C HamanoRe: How to selectively recreate merge state?
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.
Junio C HamanoRe: How to selectively recreate merge state?
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".
Jay SoffianRe: How to selectively recreate merge state?
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.
Junio C HamanoRe: How to selectively recreate merge state?
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.
Paolo BonziniRe: How to selectively recreate merge state?
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
Junio C HamanoRe: How to selectively recreate merge state?
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.