{"thread":{"id":"48417","subject":"cherry-pick --no-commit does not work well with --continue in case of conflicts","startedAt":"2018-05-05T20:27:10Z","lastAt":"2018-05-08T05:53:53Z","messageCount":4,"participants":["Ilya Kantor","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"346733","messageId":"CAFU8umjvEATZguGDmcRMcfAkqn4LW7vf_B9qpLD7uc-E_7qR9g@mail.gmail.com","threadId":"48417","inReplyTo":null,"subject":"cherry-pick --no-commit does not work well with --continue in case of conflicts","fromName":"Ilya Kantor","fromEmail":"iliakan@gmail.com","sentAt":"2018-05-05T20:26:45Z","receivedAt":"2018-05-05T20:27:10Z","isPatch":false,"sender":{"key":"iliakan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349336?v=4"},"body":"Somewhy cherry-pick --no-commit does not work well with --continue.\n\nLet's say I'm copying changes w/o committing and get a conflict:\n\n> git cherry-pick -n master..feature\nerror: could not apply 2c11f12... Run work\n\nThen I fix the conflict, but cherry-pick refuses to go on:\n\n> git add .\n> git cherry-pick --continue\nerror: your local changes would be overwritten by cherry-pick.\nfatal: cherry-pick failed\n\nIt could continue *if* I committed, but I'm --no-commit for a reason,\nso I shouldn't have to commit to go on with cherry-pick.\n\nMaybe there's a preliminary check that prevents --continue and should be fixed?\n\n---\nBest Regards,\nIlya Kantor\n"},{"id":"346743","messageId":"xmqqd0y9sdei.fsf@gitster-ct.c.googlers.com","threadId":"48417","inReplyTo":"CAFU8umjvEATZguGDmcRMcfAkqn4LW7vf_B9qpLD7uc-E_7qR9g@mail.gmail.com","subject":"Re: cherry-pick --no-commit does not work well with --continue in case of conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-05-06T02:53:25Z","receivedAt":"2018-05-06T02:53:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ilya Kantor <iliakan@gmail.com> writes:\n\n> Somewhy cherry-pick --no-commit does not work well with --continue.\n>\n> Let's say I'm copying changes w/o committing and get a conflict:\n>\n>> git cherry-pick -n master..feature\n> error: could not apply 2c11f12... Run work\n>\n> Then I fix the conflict, but cherry-pick refuses to go on:\n>\n>> git add .\n>> git cherry-pick --continue\n> error: your local changes would be overwritten by cherry-pick.\n> fatal: cherry-pick failed\n>\n> It could continue *if* I committed, but I'm --no-commit for a reason,\n> so I shouldn't have to commit to go on with cherry-pick.\n\nOf course you shouldn't have to, and cherry-pick --continue\nshouldn't commit either.\n\nOnce you resolve the conflicts, there is no more things to do for\ncherry-pick command, so --continue does not make any sense, I would\nthink, when using --no-commit.\n\nFor that matter, \"cherry-pick --no-commit A..B\", unless you are\nabsolutely sure A..B consists of only one commit (in which case you\nshould just be saying \"cherry-pick --no-commit B\" instead), makes no\nsense, either.\n\nSo perhaps these are what we should be fixing?  I.e. reject\nrange-pick when --no-commit is given, and reject --continue when\nworking in --no-commit mode.\n"},{"id":"346747","messageId":"CAFU8umjw-gz1UGHwiopHRJ-+v+KS2USqXV-9Qs0ieW8GaLpUsA@mail.gmail.com","threadId":"48417","inReplyTo":"xmqqd0y9sdei.fsf@gitster-ct.c.googlers.com","subject":"Re: cherry-pick --no-commit does not work well with --continue in case of conflicts","fromName":"Ilya Kantor","fromEmail":"iliakan@gmail.com","sentAt":"2018-05-06T05:17:03Z","receivedAt":"2018-05-06T05:19:11Z","isPatch":false,"sender":{"key":"iliakan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349336?v=4"},"body":"Let's say master..feature has 2 commits: A and B.\n\nThen `git cherry-pick -n master..feature` should pick-up A and then B\ninto the working directory and the index.\n\nIf applying A leads to a conflict, then it stops on A, like here:\n>>> git cherry-pick -n master..feature\n>> error: could not apply 2c11f12... Run work\n\nThen I add the fix to the index, and should be able to continue on (B\nis yet unpicked):\n\n>>> git add .\n>>> git cherry-pick --continue\n>> error: your local changes would be overwritten by cherry-pick.\n>> fatal: cherry-pick failed\n\nNow it fails.\nExpected behavior: should continue with picking B.\n\nP.S. I assume, `cherry-pick -n <commits>` is meant to merge given\ncommits' changes into the current working directory and the index,\nwithout making new commits, for any given set of commits, hope that's right?\n\nThen we should be able to --continue in case of a conflict without committing.\n"},{"id":"346968","messageId":"xmqqr2mmlml0.fsf@gitster-ct.c.googlers.com","threadId":"48417","inReplyTo":"CAFU8umjw-gz1UGHwiopHRJ-+v+KS2USqXV-9Qs0ieW8GaLpUsA@mail.gmail.com","subject":"Re: cherry-pick --no-commit does not work well with --continue in case of conflicts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-05-08T05:53:47Z","receivedAt":"2018-05-08T05:53:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ilya Kantor <iliakan@gmail.com> writes:\n\n> P.S. I assume, `cherry-pick -n <commits>` is meant to merge given\n> commits' changes into the current working directory and the index,\n> without making new commits, for any given set of commits, hope that's right?\n\nHmph.\n\nOne step in cherry-pick should refuse to start when HEAD and the index\ndoes not match, even though it is perfectly OK if the working tree\nfiles do not match the index, as long as such local changes do not\ninterfere with the change the cherry-pick tries to bring in.\n\nThe requirement for the index to be clean wrt the HEAD is\nfundamental.  When any merge-y operation like cherry-pick, apply -3,\ncheckout -m, etc., happens, we would want to\n\n * store the cleanly automerged contents to the index\n\n * store common-ancestor, ours and theirs for conflicted merge to\n   the stages in the index.\n\nand being able to safely say \"git reset\" (not \"reset --hard\") to\nbring the index back to the state before the merge-y operation has\nstarted.  Not noticing a dirty index and starting a step in cherry-pick\nmeans you cannot tell cleanly automerged paths from paths you had\nmodified in the index _before_ the step started.\n\nAnd if you have a range that consists of two commits and\nsuccessfully did \"cherry-pick -n\" on the first one, because the\ncommand is not committing, these cleanly merged paths will be\nmodified in the index.  Then the next step to pick the second commit\nmay conflict---after that, you lose the result of the first pick\nfrom the index as some changes from the second step is already\nintermixed with the result from the first step in the index.\n\nSo, no.  I do not think it makes sense to feed multiple commits to\n\"cherry-pick -n\".\n"}]}