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@xxxxxxxxxxx>
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@xxxxxxxxxxx>
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)$
Attachment:
commit-swap.fexp
Description: Binary data
