* How to selectively recreate merge state? @ 2009-12-10 23:56 Jay Soffian 2009-12-11 0:04 ` Junio C Hamano 0 siblings, 1 reply; 28+ messages in thread From: Jay Soffian @ 2009-12-10 23:56 UTC (permalink / raw) To: git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 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 0 siblings, 1 reply; 28+ messages in thread From: Junio C Hamano @ 2009-12-11 0:04 UTC (permalink / raw) To: Jay Soffian; +Cc: git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 0:04 ` Junio C Hamano @ 2009-12-11 0:28 ` Jakub Narebski 2009-12-11 1:11 ` Junio C Hamano 0 siblings, 1 reply; 28+ messages in thread From: Jakub Narebski @ 2009-12-11 0:28 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 0:28 ` Jakub Narebski @ 2009-12-11 1:11 ` Junio C Hamano 2009-12-11 1:33 ` Jakub Narebski 0 siblings, 1 reply; 28+ messages in thread From: Junio C Hamano @ 2009-12-11 1:11 UTC (permalink / raw) To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 1:11 ` Junio C Hamano @ 2009-12-11 1:33 ` Jakub Narebski 2009-12-11 10:44 ` Michael J Gruber 0 siblings, 1 reply; 28+ messages in thread From: Jakub Narebski @ 2009-12-11 1:33 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 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 11:20 ` Jakub Narebski 0 siblings, 2 replies; 28+ messages in thread From: Michael J Gruber @ 2009-12-11 10:44 UTC (permalink / raw) To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git 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... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 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 1 sibling, 1 reply; 28+ messages in thread From: Björn Steinbrink @ 2009-12-11 11:09 UTC (permalink / raw) To: Michael J Gruber; +Cc: Jakub Narebski, Junio C Hamano, Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 11:09 ` Björn Steinbrink @ 2009-12-11 12:51 ` Thomas Rast 0 siblings, 0 replies; 28+ messages in thread From: Thomas Rast @ 2009-12-11 12:51 UTC (permalink / raw) To: Björn Steinbrink Cc: Michael J Gruber, Jakub Narebski, Junio C Hamano, Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 10:44 ` Michael J Gruber 2009-12-11 11:09 ` Björn Steinbrink @ 2009-12-11 11:20 ` Jakub Narebski 2009-12-11 12:33 ` Michael J Gruber 2009-12-11 20:38 ` How to selectively recreate merge state? Paolo Bonzini 1 sibling, 2 replies; 28+ messages in thread From: Jakub Narebski @ 2009-12-11 11:20 UTC (permalink / raw) To: Michael J Gruber; +Cc: Junio C Hamano, Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 11:20 ` Jakub Narebski @ 2009-12-11 12:33 ` Michael J Gruber 2009-12-11 14:00 ` Jakub Narebski 2009-12-11 20:38 ` How to selectively recreate merge state? Paolo Bonzini 1 sibling, 1 reply; 28+ messages in thread From: Michael J Gruber @ 2009-12-11 12:33 UTC (permalink / raw) To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 12:33 ` Michael J Gruber @ 2009-12-11 14:00 ` Jakub Narebski 2009-12-11 14:57 ` Michael J Gruber 2009-12-11 19:24 ` Junio C Hamano 0 siblings, 2 replies; 28+ messages in thread From: Jakub Narebski @ 2009-12-11 14:00 UTC (permalink / raw) To: Michael J Gruber; +Cc: Junio C Hamano, Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 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 1 sibling, 1 reply; 28+ messages in thread From: Michael J Gruber @ 2009-12-11 14:57 UTC (permalink / raw) To: Jakub Narebski; +Cc: Junio C Hamano, Jay Soffian, git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 14:57 ` Michael J Gruber @ 2009-12-11 15:35 ` Junio C Hamano 0 siblings, 0 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-11 15:35 UTC (permalink / raw) To: Michael J Gruber; +Cc: Jakub Narebski, Jay Soffian, git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 14:00 ` Jakub Narebski 2009-12-11 14:57 ` Michael J Gruber @ 2009-12-11 19:24 ` Junio C Hamano 2009-12-11 22:18 ` Jay Soffian 1 sibling, 1 reply; 28+ messages in thread From: Junio C Hamano @ 2009-12-11 19:24 UTC (permalink / raw) To: Jakub Narebski; +Cc: Michael J Gruber, Johannes Sixt, Jay Soffian, git 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". ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 19:24 ` Junio C Hamano @ 2009-12-11 22:18 ` Jay Soffian 2009-12-11 23:46 ` Junio C Hamano 0 siblings, 1 reply; 28+ messages in thread From: Jay Soffian @ 2009-12-11 22:18 UTC (permalink / raw) To: Junio C Hamano; +Cc: Jakub Narebski, Michael J Gruber, Johannes Sixt, git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 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 0 siblings, 1 reply; 28+ messages in thread From: Junio C Hamano @ 2009-12-11 23:46 UTC (permalink / raw) To: Jay Soffian; +Cc: Jakub Narebski, Michael J Gruber, Johannes Sixt, git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 0/3] Update advice in commit/status output 2009-12-11 23:46 ` Junio C Hamano @ 2009-12-12 9:02 ` Junio C Hamano 2009-12-12 9:02 ` [PATCH 1/3] commit/status: check $GIT_DIR/MERGE_HEAD only once Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-12 9:02 UTC (permalink / raw) To: git 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(-) ^ permalink raw reply [flat|nested] 28+ messages in thread
* [PATCH 1/3] commit/status: check $GIT_DIR/MERGE_HEAD only once 2009-12-12 9:02 ` [PATCH 0/3] Update advice in commit/status output Junio C Hamano @ 2009-12-12 9:02 ` 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 16:13 ` [PATCH 0/3] Update advice in commit/status output Sverre Rabbelier 2009-12-12 22:06 ` Jay Soffian 2 siblings, 1 reply; 28+ messages in thread From: Junio C Hamano @ 2009-12-12 9:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve 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 ` Junio C Hamano 2009-12-12 9:02 ` [PATCH 3/3] status/commit: do not suggest "reset HEAD <path>" while merging Junio C Hamano ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-12 9:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* [PATCH 3/3] status/commit: do not suggest "reset HEAD <path>" while merging 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 ` 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:19 ` Nanako Shiraishi 2 siblings, 0 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-12 9:02 UTC (permalink / raw) To: git 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 ^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve 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 ` Jeff King 2009-12-12 9:24 ` Junio C Hamano 2009-12-12 9:19 ` Nanako Shiraishi 2 siblings, 1 reply; 28+ messages in thread From: Jeff King @ 2009-12-12 9:15 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve 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 0 siblings, 0 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-12 9:24 UTC (permalink / raw) To: Jeff King; +Cc: Junio C Hamano, git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 2/3] commit/status: "git add <path>" is not necessarily how to resolve 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:19 ` Nanako Shiraishi 2 siblings, 0 replies; 28+ messages in thread From: Nanako Shiraishi @ 2009-12-12 9:19 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 0/3] Update advice in commit/status output 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 16:13 ` Sverre Rabbelier 2009-12-12 18:27 ` Junio C Hamano 2009-12-12 22:06 ` Jay Soffian 2 siblings, 1 reply; 28+ messages in thread From: Sverre Rabbelier @ 2009-12-12 16:13 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 0/3] Update advice in commit/status output 2009-12-12 16:13 ` [PATCH 0/3] Update advice in commit/status output Sverre Rabbelier @ 2009-12-12 18:27 ` Junio C Hamano 0 siblings, 0 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-12 18:27 UTC (permalink / raw) To: Sverre Rabbelier; +Cc: Junio C Hamano, git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH 0/3] Update advice in commit/status output 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 16:13 ` [PATCH 0/3] Update advice in commit/status output Sverre Rabbelier @ 2009-12-12 22:06 ` Jay Soffian 2 siblings, 0 replies; 28+ messages in thread From: Jay Soffian @ 2009-12-12 22:06 UTC (permalink / raw) To: Junio C Hamano; +Cc: git 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 11:20 ` Jakub Narebski 2009-12-11 12:33 ` Michael J Gruber @ 2009-12-11 20:38 ` Paolo Bonzini 2009-12-11 21:14 ` Junio C Hamano 1 sibling, 1 reply; 28+ messages in thread From: Paolo Bonzini @ 2009-12-11 20:38 UTC (permalink / raw) To: git 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: How to selectively recreate merge state? 2009-12-11 20:38 ` How to selectively recreate merge state? Paolo Bonzini @ 2009-12-11 21:14 ` Junio C Hamano 0 siblings, 0 replies; 28+ messages in thread From: Junio C Hamano @ 2009-12-11 21:14 UTC (permalink / raw) To: Paolo Bonzini; +Cc: git, Jakub Narebski 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. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2009-12-13 1:55 UTC | newest] Thread overview: 28+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox