{"thread":{"id":"55908","subject":"v2.25 regression: cherry-pick alters patch and leaves working tree dirty","startedAt":"2021-06-12T07:40:01Z","lastAt":"2021-06-26T17:15:11Z","messageCount":4,"participants":["Anders Kaseorg","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"427175","messageId":"148044c89c194a82aa15ab0ca016669d@oc11expo7.exchange.mit.edu","threadId":"55908","inReplyTo":null,"subject":"v2.25 regression: cherry-pick alters patch and leaves working tree dirty","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2021-06-12T07:34:46Z","receivedAt":"2021-06-12T07:40:01Z","isPatch":false,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"I ran into a problem where git cherry-pick incorrectly alters a patch that should apply cleanly, and leaves the working tree dirty despite claiming to finish successfully. I minimized the problem to the reproduction recipe below. Bisecting git.git shows the problem was introduced by 49b8133a9ece199a17db8bb2545202c6eac67485 (v2.25.0-rc0~144^2~1) “merge-recursive: fix merging a subdirectory into the root directory”, and it remains a problem in v2.32.0.\n\nTo reproduce:\n\ngit init\necho foo >foo\necho bar >bar\necho baz >baz\ngit add foo bar baz\ngit commit -m 'Initial commit'\nmkdir dir\ngit mv foo dir/foo\ngit commit -am 'Move foo'\ngit mv bar dir/bar\necho baz >>baz\ngit commit -am 'Move bar'\ngit tag move-bar\ngit reset --hard move-bar~2\ngit cherry-pick move-bar\n\nThe rename part of the patch has been unexpectedly lost, and ‘bar’ has been unexpectedly deleted from the working tree:\n\n$ git show\ncommit f06592b45db70540983a6c3e8bcf62712c694257\nAuthor: Anders Kaseorg <andersk@mit.edu>\nDate:   Sat Jun 12 00:20:13 2021 -0700\n\n    Move bar\n\ndiff --git a/baz b/baz\nindex 7601807..1f55335 100644\n--- a/baz\n+++ b/baz\n@@ -1 +1,2 @@\n baz\n+baz\n\n$ git status\nOn branch master\nChanges not staged for commit:\n  (use \"git add/rm <file>...\" to update what will be committed)\n  (use \"git restore <file>...\" to discard changes in working directory)\n\tdeleted:    bar\n\nno changes added to commit (use \"git add\" and/or \"git commit -a\")\n\nBefore 49b8133a9e, the results are as expected:\n\n$ git show\ncommit b7a2a3505dae3589203ca4469cb49e8a8e2727c3\nAuthor: Anders Kaseorg <andersk@mit.edu>\nDate:   Sat Jun 12 00:23:07 2021 -0700\n\n    Move bar\n\ndiff --git a/baz b/baz\nindex 7601807..1f55335 100644\n--- a/baz\n+++ b/baz\n@@ -1 +1,2 @@\n baz\n+baz\ndiff --git a/bar b/dir/bar\nsimilarity index 100%\nrename from bar\nrename to dir/bar\n\n$ git status\nOn branch master\nnothing to commit, working tree clean\n\nAnders\n"},{"id":"427218","messageId":"CABPp-BGDfucqae=HNES_QmmsjpDbdHrR6CG=H3gtiDygHzquVg@mail.gmail.com","threadId":"55908","inReplyTo":"148044c89c194a82aa15ab0ca016669d@oc11expo7.exchange.mit.edu","subject":"Re: v2.25 regression: cherry-pick alters patch and leaves working tree dirty","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-13T06:57:38Z","receivedAt":"2021-06-13T06:58:07Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Jun 12, 2021 at 12:34 AM Anders Kaseorg <andersk@mit.edu> wrote:\n>\n> I ran into a problem where git cherry-pick incorrectly alters a patch that should apply cleanly, and leaves the working tree dirty despite claiming to finish successfully. I minimized the problem to the reproduction recipe below. Bisecting git.git shows the problem was introduced by 49b8133a9ece199a17db8bb2545202c6eac67485 (v2.25.0-rc0~144^2~1) “merge-recursive: fix merging a subdirectory into the root directory”, and it remains a problem in v2.32.0.\n>\n> To reproduce:\n>\n> git init\n> echo foo >foo\n> echo bar >bar\n> echo baz >baz\n> git add foo bar baz\n> git commit -m 'Initial commit'\n> mkdir dir\n> git mv foo dir/foo\n> git commit -am 'Move foo'\n> git mv bar dir/bar\n> echo baz >>baz\n> git commit -am 'Move bar'\n> git tag move-bar\n> git reset --hard move-bar~2\n> git cherry-pick move-bar\n>\n> The rename part of the patch has been unexpectedly lost, and ‘bar’ has been unexpectedly deleted from the working tree:\n>\n> $ git show\n> commit f06592b45db70540983a6c3e8bcf62712c694257\n> Author: Anders Kaseorg <andersk@mit.edu>\n> Date:   Sat Jun 12 00:20:13 2021 -0700\n>\n>     Move bar\n>\n> diff --git a/baz b/baz\n> index 7601807..1f55335 100644\n> --- a/baz\n> +++ b/baz\n> @@ -1 +1,2 @@\n>  baz\n> +baz\n>\n> $ git status\n> On branch master\n> Changes not staged for commit:\n>   (use \"git add/rm <file>...\" to update what will be committed)\n>   (use \"git restore <file>...\" to discard changes in working directory)\n>         deleted:    bar\n>\n> no changes added to commit (use \"git add\" and/or \"git commit -a\")\n>\n> Before 49b8133a9e, the results are as expected:\n>\n> $ git show\n> commit b7a2a3505dae3589203ca4469cb49e8a8e2727c3\n> Author: Anders Kaseorg <andersk@mit.edu>\n> Date:   Sat Jun 12 00:23:07 2021 -0700\n>\n>     Move bar\n>\n> diff --git a/baz b/baz\n> index 7601807..1f55335 100644\n> --- a/baz\n> +++ b/baz\n> @@ -1 +1,2 @@\n>  baz\n> +baz\n> diff --git a/bar b/dir/bar\n> similarity index 100%\n> rename from bar\n> rename to dir/bar\n>\n> $ git status\n> On branch master\n> nothing to commit, working tree clean\n>\n> Anders\n\nThanks for the detailed report, and going the extra mile to come up\nwith a simple testcase.  Very helpful.\n\nThere's two bugs here, and they actually predate v2.25.  If you put\nall your files in a subdirectory (e.g. 'subdir/bar' instead of 'bar'\nand 'subdir/dir/bar' instead of 'dir/bar'), then the same bug\nreproduces going back many more versions.  The changes in v2.25 to\nsupport directory rename detection of a subdirectory to the root just\nallowed this bug to happen at the toplevel as well.\n\nAlso, one of the two bugs affects merge-ort (in addition to merge-recursive).\n\nI've got a one-liner fix to merge-ort.c, plus two additional lines\nchanged to audit for similar bugs in merge-ort and make sure they just\ncan't happen.  I was hoping to also have patches to fix\nmerge-recursive as well, but despite spending more time on it than on\nmerge-ort, I wasn't yet able to track down either of those two bugs.\nI'll try again next week.\n"},{"id":"427225","messageId":"9ef09567-d69c-0fba-a09c-70095a21a3a9@mit.edu","threadId":"55908","inReplyTo":"CABPp-BGDfucqae=HNES_QmmsjpDbdHrR6CG=H3gtiDygHzquVg@mail.gmail.com","subject":"Re: v2.25 regression: cherry-pick alters patch and leaves working tree dirty","fromName":"Anders Kaseorg","fromEmail":"andersk@mit.edu","sentAt":"2021-06-13T07:45:33Z","receivedAt":"2021-06-13T07:45:38Z","isPatch":false,"sender":{"key":"andersk@mit.edu","avatar":"https://avatars.githubusercontent.com/u/26471?v=4"},"body":"On 6/12/21 11:57 PM, Elijah Newren wrote:\n> There's two bugs here, and they actually predate v2.25.  If you put\n> all your files in a subdirectory (e.g. 'subdir/bar' instead of 'bar'\n> and 'subdir/dir/bar' instead of 'dir/bar'), then the same bug\n> reproduces going back many more versions.  The changes in v2.25 to\n> support directory rename detection of a subdirectory to the root just\n> allowed this bug to happen at the toplevel as well.\n\nYou’re right.  I’m sure you’ve already done this bisect, but for \nposterity, after that modification to the test case (‘mkdir subdir; cd \nsubdir’ after ‘git init’), it reproduces back as far as \n9c0743fe1e45b3a0ffe166ac949a27f95a3e5c34 (v2.18.0-rc0~2^2~20) \n“merge-recursive: apply necessary modifications for directory renames”.\n\nThanks for the quick investigation!\n\nAnders\n"},{"id":"428528","messageId":"CABPp-BFqpdjZVY6Jw4tz7z+4UdiPJpD+1Ymv=6QVBm_Apb3xbQ@mail.gmail.com","threadId":"55908","inReplyTo":"9ef09567-d69c-0fba-a09c-70095a21a3a9@mit.edu","subject":"Re: v2.25 regression: cherry-pick alters patch and leaves working tree dirty","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2021-06-26T17:14:53Z","receivedAt":"2021-06-26T17:15:11Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Jun 13, 2021 at 12:45 AM Anders Kaseorg <andersk@mit.edu> wrote:\n>\n> On 6/12/21 11:57 PM, Elijah Newren wrote:\n> > There's two bugs here, and they actually predate v2.25.  If you put\n> > all your files in a subdirectory (e.g. 'subdir/bar' instead of 'bar'\n> > and 'subdir/dir/bar' instead of 'dir/bar'), then the same bug\n> > reproduces going back many more versions.  The changes in v2.25 to\n> > support directory rename detection of a subdirectory to the root just\n> > allowed this bug to happen at the toplevel as well.\n>\n> You’re right.  I’m sure you’ve already done this bisect, but for\n> posterity, after that modification to the test case (‘mkdir subdir; cd\n> subdir’ after ‘git init’), it reproduces back as far as\n> 9c0743fe1e45b3a0ffe166ac949a27f95a3e5c34 (v2.18.0-rc0~2^2~20)\n> “merge-recursive: apply necessary modifications for directory renames”.\n>\n> Thanks for the quick investigation!\n>\n> Anders\n\nPatches posted here:\nhttps://lore.kernel.org/git/pull.1039.git.git.1624727121.gitgitgadget@gmail.com/\n"}]}