Re: [BUG] bulk move silently dropped, leaving the "delete" part in work dir, on commit reorder (rebase -i)

[Elijah Newren <newren@gmail.com>]

Hi,

On Tue, Apr 7, 2020 at 9:03 AM <ydirson@free.fr> wrote:
>
> Hello all,
>
> Please find attached a fast-export test-case for the problem.  It contains an "original state" commit
> and 2 commits moving lots of files around.  As context, the first one is a logical fixup of the second
> one, adding one more move to the bulk move in the second commit.
>
> If I use "rebase -i" to reorder the 2 commits, "subject 1" which originally contains 4 blob changes and
> 324 moves, loses all the renames.  Problem exists at least in 2.25.1 and 2.26.0 as shipped in Debian testing.
>
> Additionally, the files in workdir are all locally deleted and stay there as "Changes not staged for commit",
> which should have prevented the rebase from proceeding to the second "pick".
>
>  (ref0/ref1)$ git log --raw HEAD^^..
> commit d368ee70ca358f4877185175780147b5bfba0ec5 (HEAD -> ref0/ref1)
> Author: User 0 <user0@example.com>
> Date:   Thu Apr 2 17:15:29 2020 +0200
>
>     subject 1
>
>     body
>
> :100644 100644 16fd26f 16fd26f R100     path15/path30/path89/path102/path106/path107    path15/path607/path30/path89/path102/path106/path107
>
> commit a6b4902d848acdeeb0238d22dd7a093317e7a389
> Author: User 0 <user0@example.com>
> Date:   Wed Apr 1 18:14:31 2020 +0200
>
>     subject 2
>
>     body
>
> :100644 100644 386a5e0 67bb842 M        path12/path10
> :100644 100644 703e2a3 57729f1 M        path13/path10
> :100644 100644 386a5e0 67bb842 M        path14/path10
> :100644 100644 53d9ddb fe616ea M        path9/path10
>  (ref0/ref1)$

Thanks for the report.  The testcase was slightly hard to understand
from the description at first, but it's basically:

    # download the file that Yann attached
    cat $DOWNLOADED_FILE | git fast-import --quiet
    git checkout -b testing ref0/ref1
    git rebase -i HEAD~2
    # Swap the two pick lines, save & exit editor

at which point the rebase will complete with a report of success, but
it will drop most the changes in the "subject 2" patch, and leave the
working directory quite dirty at the end despite the fact that it
started out clean.


One can also duplicate this bug using cherry-pick or merge-recursive;
for example, assuming the testing branch was already created as above:
    git reset --hard testing ref0/ref1~2
    git cherry-pick ref0/ref1


This bug goes back to at least git-2.20 and likely earlier.

I tested with the ort merge strategy and it happens to fix this bug
(among others), so maybe if rebase stuff ever quiets down then I can
address this bug just by pushing that new strategy forward.