{"thread":{"id":"53178","subject":"[BUG] bulk move silently dropped, leaving the \"delete\" part in work dir, on commit reorder (rebase -i)","startedAt":"2020-04-07T16:02:10Z","lastAt":"2020-04-07T20:10:41Z","messageCount":2,"participants":["ydirson@free.fr","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"394971","messageId":"1537903963.805193304.1586275292611.JavaMail.root@zimbra39-e7","threadId":"53178","inReplyTo":"1249625346.805132902.1586274429644.JavaMail.root@zimbra39-e7","subject":"[BUG] bulk move silently dropped, leaving the \"delete\" part in work dir, on commit reorder (rebase -i)","fromName":"","fromEmail":"ydirson@free.fr","sentAt":"2020-04-07T16:01:32Z","receivedAt":"2020-04-07T16:02:10Z","isPatch":false,"sender":{"key":"ydirson@free.fr","avatar":null},"body":"Hello all,\n\nPlease find attached a fast-export test-case for the problem.  It contains an \"original state\" commit\nand 2 commits moving lots of files around.  As context, the first one is a logical fixup of the second\none, adding one more move to the bulk move in the second commit.\n\nIf I use \"rebase -i\" to reorder the 2 commits, \"subject 1\" which originally contains 4 blob changes and\n324 moves, loses all the renames.  Problem exists at least in 2.25.1 and 2.26.0 as shipped in Debian testing.\n\nAdditionally, the files in workdir are all locally deleted and stay there as \"Changes not staged for commit\",\nwhich should have prevented the rebase from proceeding to the second \"pick\".\n\n (ref0/ref1)$ git log --raw HEAD^^..\ncommit d368ee70ca358f4877185175780147b5bfba0ec5 (HEAD -> ref0/ref1)\nAuthor: User 0 <user0@example.com>\nDate:   Thu Apr 2 17:15:29 2020 +0200\n\n    subject 1\n    \n    body\n\n:100644 100644 16fd26f 16fd26f R100     path15/path30/path89/path102/path106/path107    path15/path607/path30/path89/path102/path106/path107\n\ncommit a6b4902d848acdeeb0238d22dd7a093317e7a389\nAuthor: User 0 <user0@example.com>\nDate:   Wed Apr 1 18:14:31 2020 +0200\n\n    subject 2\n    \n    body\n\n:100644 100644 386a5e0 67bb842 M        path12/path10\n:100644 100644 703e2a3 57729f1 M        path13/path10\n:100644 100644 386a5e0 67bb842 M        path14/path10\n:100644 100644 53d9ddb fe616ea M        path9/path10\n (ref0/ref1)$ \n"},{"id":"395004","messageId":"CABPp-BH=XcX6tsSAu9bN-qk2h0ayj+rqmdJWwYwvCGnpKivGHw@mail.gmail.com","threadId":"53178","inReplyTo":"1537903963.805193304.1586275292611.JavaMail.root@zimbra39-e7","subject":"Re: [BUG] bulk move silently dropped, leaving the \"delete\" part in work dir, on commit reorder (rebase -i)","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-04-07T20:10:26Z","receivedAt":"2020-04-07T20:10:41Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nOn Tue, Apr 7, 2020 at 9:03 AM <ydirson@free.fr> wrote:\n>\n> Hello all,\n>\n> Please find attached a fast-export test-case for the problem.  It contains an \"original state\" commit\n> and 2 commits moving lots of files around.  As context, the first one is a logical fixup of the second\n> one, adding one more move to the bulk move in the second commit.\n>\n> If I use \"rebase -i\" to reorder the 2 commits, \"subject 1\" which originally contains 4 blob changes and\n> 324 moves, loses all the renames.  Problem exists at least in 2.25.1 and 2.26.0 as shipped in Debian testing.\n>\n> Additionally, the files in workdir are all locally deleted and stay there as \"Changes not staged for commit\",\n> which should have prevented the rebase from proceeding to the second \"pick\".\n>\n>  (ref0/ref1)$ git log --raw HEAD^^..\n> commit d368ee70ca358f4877185175780147b5bfba0ec5 (HEAD -> ref0/ref1)\n> Author: User 0 <user0@example.com>\n> Date:   Thu Apr 2 17:15:29 2020 +0200\n>\n>     subject 1\n>\n>     body\n>\n> :100644 100644 16fd26f 16fd26f R100     path15/path30/path89/path102/path106/path107    path15/path607/path30/path89/path102/path106/path107\n>\n> commit a6b4902d848acdeeb0238d22dd7a093317e7a389\n> Author: User 0 <user0@example.com>\n> Date:   Wed Apr 1 18:14:31 2020 +0200\n>\n>     subject 2\n>\n>     body\n>\n> :100644 100644 386a5e0 67bb842 M        path12/path10\n> :100644 100644 703e2a3 57729f1 M        path13/path10\n> :100644 100644 386a5e0 67bb842 M        path14/path10\n> :100644 100644 53d9ddb fe616ea M        path9/path10\n>  (ref0/ref1)$\n\nThanks for the report.  The testcase was slightly hard to understand\nfrom the description at first, but it's basically:\n\n    # download the file that Yann attached\n    cat $DOWNLOADED_FILE | git fast-import --quiet\n    git checkout -b testing ref0/ref1\n    git rebase -i HEAD~2\n    # Swap the two pick lines, save & exit editor\n\nat which point the rebase will complete with a report of success, but\nit will drop most the changes in the \"subject 2\" patch, and leave the\nworking directory quite dirty at the end despite the fact that it\nstarted out clean.\n\n\nOne can also duplicate this bug using cherry-pick or merge-recursive;\nfor example, assuming the testing branch was already created as above:\n    git reset --hard testing ref0/ref1~2\n    git cherry-pick ref0/ref1\n\n\nThis bug goes back to at least git-2.20 and likely earlier.\n\nI tested with the ort merge strategy and it happens to fix this bug\n(among others), so maybe if rebase stuff ever quiets down then I can\naddress this bug just by pushing that new strategy forward.\n"}]}