{"thread":{"id":"30080","subject":"git add -p and unresolved conflicts","startedAt":"2012-03-28T09:51:11Z","lastAt":"2012-03-30T08:11:09Z","messageCount":21,"participants":["Erik Faye-Lund","Junio C Hamano","Matthieu Moy","Holger Hellmuth","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"187922","messageId":"CABPQNSYVXMxS3kugu1j=62ArJ_1saYYfMjJdZvqhjgPFGN=Eqw@mail.gmail.com","threadId":"30080","inReplyTo":null,"subject":"git add -p and unresolved conflicts","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-03-28T09:51:11Z","receivedAt":"2012-03-28T09:51:11Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"I'm running git version 1.7.9.msysgit.0.390.g01fca.dirty, and I've\nnoticed a puzzling behavior with \"git add -p\" on a conflicted file: it\nseems to simply spew the diff and exit the process.\n\nIs this the expected behavior? It doesn't seem very useful to me...\n\nHere's how to reproduce the behavior:\n\ngit init /tmp/git-add--p-conflict\ncd /tmp/git-add--p-conflict/\necho \"foo\" > bar.txt\ngit add bar.txt\ngit commit -m.\necho \"bar\" >> bar.txt\ngit stash save\necho \"baz\" >> bar.txt\ngit commit -am.\ngit stash pop\ngit add -p bar.txt\n"},{"id":"187934","messageId":"7vbongyd67.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"CABPQNSYVXMxS3kugu1j=62ArJ_1saYYfMjJdZvqhjgPFGN=Eqw@mail.gmail.com","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T15:10:08Z","receivedAt":"2012-03-28T15:10:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erik Faye-Lund writes:\n\n> I'm running git version 1.7.9.msysgit.0.390.g01fca.dirty, and I've\n> noticed a puzzling behavior with \"git add -p\" on a conflicted file: it\n> seems to simply spew the diff and exit the process.\n\nYeah, when I wrote the 'p'atch mode in \"add--interactive\", I wasn't\ninterested at all in letting it be used on a conflicted path, so that is\nnot a designed-in behaviour but merely whatever it happens to do. So at\nleast it should not allow the user to pick a path that has conflicts in\nit.\n\nWhat the behaviour for people who *do* want to use the patch mode for\nconflicted paths should be is a separate matter. As I said, I am not\ninterested in it, so I wouldn't be the best person to design it.\n\nI mildly suspect nobody would come up with a sane behaviour, but what\nwould I know...\n"},{"id":"187936","messageId":"vpqvclozr7e.fsf@bauges.imag.fr","threadId":"30080","inReplyTo":"7vbongyd67.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-28T15:21:41Z","receivedAt":"2012-03-28T15:21:41Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> I mildly suspect nobody would come up with a sane behaviour, but what\n> would I know...\n\nDesigning a per-hunk behavior would clearly be very tricky.\n\nBut a simple way to deal with this would be to show the whole-file\npatch, and ask \"stage this file (yes/no)?\".\n\nMy fingers are used to typing\n\ngit add -p\ny\ny\ny\ngit commit\n\nand they would appreciate if it worked in the presence of conflicts.\nMost of the time, I have small conflicts, so a whole-file behavior\nwouldn't be disturbing, but I like seeing the changes before commiting\nthem.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187938","messageId":"CABPQNSYp7k82mjzNqZmBX+7Dh6R7rgjQ3ZNqikZyM71GshMqqg@mail.gmail.com","threadId":"30080","inReplyTo":"7vbongyd67.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-03-28T15:33:46Z","receivedAt":"2012-03-28T15:33:46Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Mar 28, 2012 at 5:10 PM, Junio C Hamano wrote:\n> Erik Faye-Lund writes:\n>\n>> I'm running git version 1.7.9.msysgit.0.390.g01fca.dirty, and I've\n>> noticed a puzzling behavior with \"git add -p\" on a conflicted file: it\n>> seems to simply spew the diff and exit the process.\n>\n> Yeah, when I wrote the 'p'atch mode in \"add--interactive\", I wasn't\n> interested at all in letting it be used on a conflicted path, so that is\n> not a designed-in behaviour but merely whatever it happens to do.\n\nOK, that's pretty much what I suspected ;)\n\n> So at\n> least it should not allow the user to pick a path that has conflicts in\n> it.\n\nSo, the options are:\n 1) Keep the current behavior\n 2) Abort with an error immediately if one of the picked paths are in\na conflicted state\n 3) Abort with an error when first encounter a path that is in a\nconflicted state\n 4) Warn and skip any paths that are in a conflicted state\n 5) Implement \"git add -p\" for conflicted files (if we can agree on a behavior)\n\n1) and 3) makes little sense to me. 5) only makes sense if we can\nagree on what should have happened.\n\n> What the behaviour for people who *do* want to use the patch mode for\n> conflicted paths should be is a separate matter.  As I said, I am not\n> interested in it, so I wouldn't be the best person to design it.\n>\n> I mildly suspect nobody would come up with a sane behaviour, but what\n> would I know...\n\nWell, I can explain what I expected to happen:\n\nI had stashed away some of my \"hacking\"-code to rebase a branch to the\ncurrent master. I was going to stage parts of the stashed changes as a\ncommit on top. However after rebasing, \"git stash pop\" lead to a\nconflict. So I manually resolved the conflicts, but only wanted to\nstage some of the hunks to be committed.\n\nNow, what is obvious in hindsight, is that I should simply have done\n\"git reset\" after resolving the conflicts manually. When I do \"git add\n-p\", I add hunks to the index. But for a conflicted file, the index\nisn't in a well-defined state (or, the contents of the file is in a\nnot-yet-defined state).\n\nHowever, as it happened it made me confused (and a little bit\nfrustrated). I suspect this could confuse other users as well. Perhaps\nwe should implement 1) or 3) and come up with a helpful error/warning\nmessage? I don't have a very strong opinion on which one is better,\nbut I suspect 3) is easier.\n"},{"id":"187953","messageId":"7vehscwspt.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"CABPQNSYp7k82mjzNqZmBX+7Dh6R7rgjQ3ZNqikZyM71GshMqqg@mail.gmail.com","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T17:17:18Z","receivedAt":"2012-03-28T17:17:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erik Faye-Lund writes:\n\n> So, the options are:\n> 1) Keep the current behavior\n> 2) Abort with an error immediately if one of the picked paths are in\n> a conflicted state\n> 3) Abort with an error when first encounter a path that is in a\n> conflicted state\n> 4) Warn and skip any paths that are in a conflicted state\n> 5) Implement \"git add -p\" for conflicted files (if we can agree on a behavior)\n>\n> 1) and 3) makes little sense to me.\n\nI do not think 1, 2, or 3 makes any sense to me if you are proposing to\nchange anything. Why did you even bother to list them?\n\nGiven that you wrote \"(if we can...)\" for #5, in the short term, #4 is the\nonly sensible thing to do, I would think.\n"},{"id":"187972","messageId":"4F73632E.1060408@ira.uka.de","threadId":"30080","inReplyTo":"vpqvclozr7e.fsf@bauges.imag.fr","subject":"Re: git add -p and unresolved conflicts","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-28T19:14:54Z","receivedAt":"2012-03-28T19:14:54Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 28.03.2012 17:21, Matthieu Moy wrote:\n> Junio C Hamano writes:\n>\n>> I mildly suspect nobody would come up with a sane behaviour, but what\n>> would I know...\n>\n> Designing a per-hunk behavior would clearly be very tricky.\n>\n\nI don't think it's that tricky:\n\nFor a conflicted file show any conflicted hunks first(!) and only \nprovide the following options for them:\nq - quit, do not stage...\nd - do not stage this hunk nor any of the remaining hunks in the file\ne - manually edit the current hunk\n? - print help\n\nand additionally the following three options:\nb - choose the base version\n< - choose our version\n > - choose their version\n\n< and > correspond to the conflict markers, alternatives would be o and t\n\nThe user now has the option to remove the conflicts (through editing or \nchoosing one of the versions) or abort adding the file.\n\nThe tricky part might be sorting the hunks so that conflicts are first \n(depending on how the code works now), choosing the right version in a \nhunk (the three new options) should be relatively easy.\n"},{"id":"187974","messageId":"7vmx70v8ho.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"4F73632E.1060408@ira.uka.de","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T19:19:31Z","receivedAt":"2012-03-28T19:19:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Holger Hellmuth writes:\n\n> I don't think it's that tricky:\n> ...\n> The tricky part might be sorting the hunks so that conflicts are first\n> (depending on how the code works now), choosing the right version in a\n> hunk (the three new options) should be relatively easy.\n\nCode it and then tell us if it is tricky or not. Until then, especially\nwhen you have to say \"depending on how the code works now\", implying you\ndo not know, why should we even listen to you?\n"},{"id":"187978","messageId":"vpqk424zfb1.fsf@bauges.imag.fr","threadId":"30080","inReplyTo":"4F73632E.1060408@ira.uka.de","subject":"Re: git add -p and unresolved conflicts","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-28T19:38:42Z","receivedAt":"2012-03-28T19:38:42Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Holger Hellmuth writes:\n\n> and additionally the following three options:\n> b - choose the base version\n> < - choose our version\n> > - choose their version\n\nWhat does it mean to \"choose\" in this context? In general, it means \"put\nthis into the index\", but if the file is in conflicted state, you have 3\ndifferent versions of the file in the index.\n\nAnd you miss the most usefull (to me at least): \"choose the version in\nthe worktree\".\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"187984","messageId":"4F736C17.4000403@ira.uka.de","threadId":"30080","inReplyTo":"7vmx70v8ho.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-28T19:52:55Z","receivedAt":"2012-03-28T19:52:55Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 28.03.2012 21:19, Junio C Hamano wrote:\n> Holger Hellmuth writes:\n>\n>> I don't think it's that tricky:\n\nI was assuming this \"tricky\" was about a sensible user interface.\n\n>> ...\n>> The tricky part might be sorting the hunks so that conflicts are first\n>> (depending on how the code works now), choosing the right version in a\n>> hunk (the three new options) should be relatively easy.\n>\n> Code it and then tell us if it is tricky or not. Until then, especially\n> when you have to say \"depending on how the code works now\", implying you\n> do not know, why should we even listen to you?\n\nAs it is perl I'm already looking at it. I'll try to find out if my \nmeagre programming skills can do something here.\n"},{"id":"187985","messageId":"7v8vikv6v5.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"vpqk424zfb1.fsf@bauges.imag.fr","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T19:54:38Z","receivedAt":"2012-03-28T19:54:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> And you miss the most usefull (to me at least): \"choose the version in\n> the worktree\".\n\nI tend to think that \"add -p\" whose sole purpose is to make partial commit\nis fundamentally incompatible with \"am\", \"merge\" and (mostly) \"rebase\",\nwhich you do not want to record partial commit.\n\nWhen \"rebase -i\" or \"cherry-pick\" that is used for the purpose of\nreplaying only a part of a larger commit, letting \"add -p\" show the\ndifference between \"HEAD\" and the working tree version, and letting the\nuser pick hunks, would make a lot of sense, though.\n\nFor such an application, however, the user could first \"reset $path\" and\nuse \"add -p\" normally.\n"},{"id":"187989","messageId":"4F737027.5020503@ira.uka.de","threadId":"30080","inReplyTo":"vpqk424zfb1.fsf@bauges.imag.fr","subject":"Re: git add -p and unresolved conflicts","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-28T20:10:15Z","receivedAt":"2012-03-28T20:10:15Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 28.03.2012 21:38, Matthieu Moy wrote:\n> Holger Hellmuth writes:\n>\n>> and additionally the following three options:\n>> b - choose the base version\n>> < - choose our version\n>>> - choose their version\n>\n> What does it mean to \"choose\" in this context? In general, it means \"put\n> this into the index\", but if the file is in conflicted state, you have 3\n> different versions of the file in the index.\n\nThe only ways to exit with the proposed reduced options is to either \nquit adding this file (which is comparable to Eriks option 4) or \nresolving all conflicts in the file thereby allowing to add this file to \nthe index.\n\n> And you miss the most usefull (to me at least): \"choose the version in\n> the worktree\".\n>\n\nBut the conflicted chunks are of the form \"<<<< our ... |||||||||| \ntheirs >>>>>>\" in your work tree. So there are two cases:\n\na) You have removed the markers thereby removing the conflict -> this \nmeans the chunk will not be offered to you as a conflicting chunk\n\nb) You haven't removed the markers. Then there is a choice between base, \nour and their version.\nIf you had edited one of the versions between the conflict markers in \nyour working tree without removing the markers (which wouldn't be a \nsensible thing) then it depends on whether the chunk in the working tree \nor the versions in the index are used as a basis for the choosing, but I \nsuspect using the working tree version is easier to do.\n"},{"id":"187999","messageId":"7vvclotpp7.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"4F737027.5020503@ira.uka.de","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T20:50:44Z","receivedAt":"2012-03-28T20:50:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Holger Hellmuth writes:\n\n> But the conflicted chunks are of the form \"<<<< our ... ||||||||||\n> theirs >>>>>>\" in your work tree. So there are two cases:\n>\n> a) You have removed the markers thereby removing the conflict -> this\n> means the chunk will not be offered to you as a conflicting chunk\n>\n> b) You haven't removed the markers. Then there is a choice between\n> base, our and their version.\n> If you had edited one of the versions between the conflict markers in\n> your working tree without removing the markers (which wouldn't be a\n> sensible thing) then it depends on whether the chunk in the working\n> tree or the versions in the index are used as a basis for the\n> choosing, but I suspect using the working tree version is easier to\n> do.\n\nI think Matthieu is not thinking about the \"resolve conflicted merge (or\nrebase, am) and make a single commit\" use case, for which your \"pick one\nof the sides\" makes sense. His is more about \"I like some change in that\nunrelated commit---while I have no intention to replay that change as a\nwhole, I want to use \"cherry-pick --no-commit\" and pick only the bits out\nof the change that are useful for what I am doing\" use case.\n\nIn such a context, after resolving conflicts in the working tree, \"add -p\"\nwould be a good tool to pick hunks in the diff between the HEAD and the\nworking tree.\n\nI tend to think that use case, while valid, may be a minority case and\ngiving a version of \"add -p\" to make that mode too easy to use by mistake\nduring a true conflict resolution is inviting trouble for newbies. As I\nsaid, \"reset $path\" followed by regular \"add -p $path\" would be a usable\nworkaround for Matthieu's workflow.\n"},{"id":"188021","messageId":"4F7395B6.1020506@ira.uka.de","threadId":"30080","inReplyTo":"7vvclotpp7.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-28T22:50:30Z","receivedAt":"2012-03-28T22:50:30Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 28.03.2012 22:50, schrieb Junio C Hamano:\n> I think Matthieu is not thinking about the \"resolve conflicted merge (or\n> rebase, am) and make a single commit\" use case, for which your \"pick one\n> of the sides\" makes sense. His is more about \"I like some change in that\n> unrelated commit---while I have no intention to replay that change as a\n> whole, I want to use \"cherry-pick --no-commit\" and pick only the bits out\n> of the change that are useful for what I am doing\" use case.\n>\n> In such a context, after resolving conflicts in the working tree, \"add -p\"\n> would be a good tool to pick hunks in the diff between the HEAD and the\n> working tree.\n\nOk. Something like this (which is not really that different from Eriks \nexample, so I might still be missing something) ?\n\ngit init .\necho \"foo\" > bar.txt\ngit add bar.txt\ngit commit -m.\ngit checkout -b new\necho \"bar\" >> bar.txt\ngit commit -am.\ngit checkout master\ngit reset --hard\necho \"baz\" >> bar.txt\ngit commit -am.\ngit cherry-pick --no-commit new\ngit add -p bar.txt\n\nSo he would be interested in keeping his previous working tree version \n(identical to HEAD commit, otherwise cherry-pick fails) for conflicting \nchunks as they (in most cases) don't have anything to do with the chunks \nhe is interested in. In this case that is \"baz\"\n\nWhich would always be the \"ours\" side in any conflicting junks.\n\nThat suggests that he could just type '<' respective 'o' whenever a \nconflicting junk comes up as it would be the previous working tree version\n"},{"id":"188022","messageId":"7vk424s52z.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"4F7395B6.1020506@ira.uka.de","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T23:01:24Z","receivedAt":"2012-03-28T23:01:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Holger Hellmuth writes:\n\n> Am 28.03.2012 22:50, schrieb Junio C Hamano:\n>> I think Matthieu is not thinking about the \"resolve conflicted merge (or\n>> rebase, am) and make a single commit\" use case, for which your \"pick one\n>> of the sides\" makes sense. His is more about \"I like some change in that\n>> unrelated commit---while I have no intention to replay that change as a\n>> whole, I want to use \"cherry-pick --no-commit\" and pick only the bits out\n>> of the change that are useful for what I am doing\" use case.\n>>\n>> In such a context, after resolving conflicts in the working tree, \"add -p\"\n>> would be a good tool to pick hunks in the diff between the HEAD and the\n>> working tree.\n>\n> Ok. Something like this (which is not really that different from Eriks\n> example, so I might still be missing something) ?\n\nAfter re-reading what I wrote, I find that I misspoke.\n\nThere is a crucial step missing. After running \"cherry-pick --no-commit\",\nyou would eyeball the result, and typically edit the file. The conflict\nmay not be in the part of the file you are interested in picking, in which\ncase you may even leave that part as-is. And then, you would pick what\nyou want to apply to the index during per-hunk interactive patching\nsession.\n\nIn other words,...\n\n> git init .\n> echo \"foo\" > bar.txt\n> git add bar.txt\n> git commit -m.\n> git checkout -b new\n> echo \"bar\" >> bar.txt\n> git commit -am.\n> git checkout master\n> git reset --hard\n> echo \"baz\" >> bar.txt\n> git commit -am.\n> git cherry-pick --no-commit new\n\nHere, there *will* be \"edit bar.txt\" before \"add -p\". Which makes...\n\n> git add -p bar.txt\n>\n> So he would be interested in keeping his previous working tree version\n> (identical to HEAD commit, otherwise cherry-pick fails)...\n\n...this part of your analysys (and your conclusion that he can take '<')\ninvalid.\n\nNow I am not Matthieu, so he may have a different use case in mind when he\nsaid \"I want to take the version from my working tree\", but the sequence\n\"cherry-pick --no-commit ; edit ; add ; commit\" is a natural way to pick\nonly a part relevant to your current work from unrelated commit, and I\nwould understand why \"Taking the version from my working tree\" can be\nuseful in such a scenario.\n\nIn short, these two are totally different workflows and call for two\ndifferent semantics.\n"},{"id":"188023","messageId":"7vfwcss4vk.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"7vk424s52z.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-28T23:05:51Z","receivedAt":"2012-03-28T23:05:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> There is a crucial step missing. After running \"cherry-pick --no-commit\",\n> you would eyeball the result, and typically edit the file. The conflict\n> may not be in the part of the file you are interested in picking, in which\n> case you may even leave that part as-is. And then, you would pick what\n> you want to apply to the index during per-hunk interactive patching\n> session.\n\nStrictly speaking, you do not even have to edit the file. If the conflict\ndoes not overlap the part of the change you are interested in, a\nhypothetical version of \"add -p\" that is oblivious to merge conflicts\n(i.e. running \"reset $path\" before starting \"add -p\") could help you apply\nthe changes the picked commit makes relative to its parents to your\ncurrent state.\n"},{"id":"188028","messageId":"4F73BBA7.6030009@ira.uka.de","threadId":"30080","inReplyTo":"7vk424s52z.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-29T01:32:23Z","receivedAt":"2012-03-29T01:32:23Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"Am 29.03.2012 01:01, schrieb Junio C Hamano:\n> There is a crucial step missing. After running \"cherry-pick --no-commit\",\n> you would eyeball the result, and typically edit the file. The conflict\n> may not be in the part of the file you are interested in picking, in which\n> case you may even leave that part as-is. And then, you would pick what\n> you want to apply to the index during per-hunk interactive patching\n> session.\n\nBut that changes nothing. To make it clear: We have a file with chunks \nA, B and C. Only B is conflicting, but the user wants to add A or an \nedited A´ . And maybe also a new edit D.\n\nWhen he calls \"git add -p\", he gets presented with B. By picking the \n\"ours\" option (aka \"<\") he gets the version in HEAD, resolving the \nconflict and thereby allowing the add. Next he will be presented with A \n(or A´) where he can type in \"y\" and C where he can type in \"n\".\n\nResult: chunk A is added, C not, and B doesn't change from HEAD. Note he \nhad the option to use \">\" instead if it was B he wanted to cherry-pick.\n\nThe same happens if he further edited somewhere else to produce chunk D. \nAgain, after resolving the conflict of B, he is presented with A,B and D \nand can add these chunks with \"y\" or not with \"n\".\n\nThe only case I haven't talked about now is if he edits B, but that is \nthe trivial case because he would normally remove the conflict markers \nas well and git add -p would work conflict-free after the edit.\n\n> In other words,...\n>\n>> git init .\n>> echo \"foo\"> bar.txt\n>> git add bar.txt\n>> git commit -m.\n>> git checkout -b new\n>> echo \"bar\">> bar.txt\n>> git commit -am.\n>> git checkout master\n>> git reset --hard\n>> echo \"baz\">> bar.txt\n>> git commit -am.\n>> git cherry-pick --no-commit new\n>\n> Here, there *will* be \"edit bar.txt\" before \"add -p\".\n"},{"id":"188037","messageId":"20120329060853.GD27604@sigill.intra.peff.net","threadId":"30080","inReplyTo":"4F736C17.4000403@ira.uka.de","subject":"Re: git add -p and unresolved conflicts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-29T06:08:53Z","receivedAt":"2012-03-29T06:08:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 28, 2012 at 09:52:55PM +0200, Holger Hellmuth wrote:\n\n> On 28.03.2012 21:19, Junio C Hamano wrote:\n> >Holger Hellmuth writes:\n> >\n> >>I don't think it's that tricky:\n> \n> I was assuming this \"tricky\" was about a sensible user interface.\n\nI think maybe the discussion elsewhere in this thread has given you a\ntaste of the trickiness, but if you want to read more, here is a similar\ndiscussion from the same time last year (ahh, Spring, when a young man's\nthoughts turn to partial staging of conflicted hunks):\n\n http://thread.gmane.org/gmane.comp.version-control.git/168403/focus=168842\n\n-Peff\n"},{"id":"188046","messageId":"vpqvclnhnpc.fsf@bauges.imag.fr","threadId":"30080","inReplyTo":"4F737027.5020503@ira.uka.de","subject":"Re: git add -p and unresolved conflicts","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-29T07:26:55Z","receivedAt":"2012-03-29T07:26:55Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Holger Hellmuth writes:\n\n>> And you miss the most usefull (to me at least): \"choose the version in\n>> the worktree\".\n>>\n>\n> But the conflicted chunks are of the form \"<<<< our ... ||||||||||\n> theirs >>>>>>\" in your work tree. So there are two cases:\n>\n> a) You have removed the markers thereby removing the conflict -> this\n> means the chunk will not be offered to you as a conflicting chunk\n\nIf you have removed the markers, then the file is still marked as\nconflicted in the index, and the user may still want to see the combined\ndiff.\n\nMy use-case is actually quite simple: I see \"git add -p\" both as a way\nto make partial commits, and as a way to manually validate what I'm\nabout to commit. I review the diff, validate them with \"y\", and if I see\nsomething wrong, I quit \"git add -p\", fix the issue, and next \"git add\n-p\" won't show it again. This flow could work also with conflicts:\n\n$ git add -p\n# see an unresolved diff for file foo.txt\nn\n# see a resolved diff for file bar.txt\ny <-- the \"missing\" possibility for me\n$ edit foo.txt\n$ git add -p\n# see resolution for file foo.txt\ny\n$ git commit\n\nThe \"'git reset $path' before 'add -p'\" workaround is not really handy\nthere: it requires typing the path, while my workflow with \"git add -p\"\ndoes not, and it wouldn't show the combined diff, which is usually the\nbest tool to see if a merge has been resolved properly.\n\nThe current behavior is not that bad for me: I see the combined diff in\nthe output, I just have one extra \"git add $path\" to type. Being able to\njust say \"y\" instead would be handy, but not fundamentally different.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"188050","messageId":"4F74372F.1030505@ira.uka.de","threadId":"30080","inReplyTo":"20120329060853.GD27604@sigill.intra.peff.net","subject":"Re: git add -p and unresolved conflicts","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-03-29T10:19:27Z","receivedAt":"2012-03-29T10:19:27Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 29.03.2012 08:08, Jeff King wrote:\n> On Wed, Mar 28, 2012 at 09:52:55PM +0200, Holger Hellmuth wrote:\n>\n>> On 28.03.2012 21:19, Junio C Hamano wrote:\n>>> Holger Hellmuth writes:\n>>>\n>>>> I don't think it's that tricky:\n>>\n>> I was assuming this \"tricky\" was about a sensible user interface.\n>\n> I think maybe the discussion elsewhere in this thread has given you a\n> taste of the trickiness, but if you want to read more, here is a similar\n> discussion from the same time last year (ahh, Spring, when a young man's\n> thoughts turn to partial staging of conflicted hunks):\n\nIt already dawned on me that to add the proposed conflict resolution \nwould also mean changing the working copy of the file which none of the \nother options needs. Which would change the work from (assumed) surgical \nchanges to completely new routines and special cases and....\n"},{"id":"188096","messageId":"7vfwcrqfnq.fsf@alter.siamese.dyndns.org","threadId":"30080","inReplyTo":"vpqvclnhnpc.fsf@bauges.imag.fr","subject":"Re: git add -p and unresolved conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-29T21:08:09Z","receivedAt":"2012-03-29T21:08:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> The \"'git reset $path' before 'add -p'\" workaround is not really handy\n> there: it requires typing the path,...\n\nThat is exactly why \"add -i\" was written without first giving \"add -p\"\nshorthand, which spoiled you and at the same time robbed you the other\nparts of \"add -i\".\n"},{"id":"188138","messageId":"vpqiphmfqzm.fsf@bauges.imag.fr","threadId":"30080","inReplyTo":"7vfwcrqfnq.fsf@alter.siamese.dyndns.org","subject":"Re: git add -p and unresolved conflicts","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-03-30T08:11:09Z","receivedAt":"2012-03-30T08:11:09Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> The \"'git reset $path' before 'add -p'\" workaround is not really handy\n>> there: it requires typing the path,...\n>\n> That is exactly why \"add -i\" was written without first giving \"add -p\"\n> shorthand, which spoiled you and at the same time robbed you the other\n> parts of \"add -i\".\n\nQuite frankly, I never liked the interface of \"git add -i\". It saves\nvery little compared to typing \"git status\" and then doing stuff\ndirectly from the shell. \"git add -p\" on the other hand just requires\n\"y\" and \"n\" most of the time, and that really does what I want.\n\nIn the case of conflicts, I don't think \"git add -i\" solves the problem\n\"view the diff and mark it as resolved\" smoothly.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}