Re: Commit dropped when swapping commits with rebase -i -p

From: Martin Ågren <martin.agren@gmail.com>
Date: Aug 30, 2017, 18:07 UTC
Message-ID: <CAN0heSqGfxrFTwuaxgppZTx+3U=g_Qs4PyaCBF6ddV_PbvdpTQ@mail.gmail.com>
In-Reply-To: <oo62vr$pvq$1@blaine.gmane.org>

On 30 August 2017 at 12:11, Sebastian Schuberth <sschuberth@gmail.com> wrote:

Show 12 quoted lines

> Hi,
>
> I believe stumbled upon a nasty bug in Git: It looks like a commits gets dropped during interactive rebase when asking to preserve merges. Steps:
>
> $ git clone -b git-bug --single-branch https://github.com/heremaps/scancode-toolkit.git
> $ git rebase -i -p HEAD~2
> # In the editor, swap the order of the two (non-merge) commits.
> $ git diff origin/git-bug
>
> The last command will show a non-empty diff which looks as if the "Do not shadow the os package with a variable name" commit has been dropped, and indeed "git log" confirms this. The commit should not get dropped, and it does not if just using "git rebase -i -p HEAD~2" (without "-p").
>
> I'm observing this with Git 2.14.1 on Linux.

The man-page for git rebase says that combining -p with -i is "generally not a good idea unless you know what you are doing (see BUGS below)".

Under BUGS, it says

"The todo list presented by --preserve-merges --interactive does not represent the topology of the revision graph. Editing commits and rewording their commit messages should work fine, but attempts to reorder commits tend to produce counterintuitive results."

So if you agree that a "dropped commit" is a "counterintuitive result", this is known and documented. Maybe the warning could be harsher, but it does say "unless you know what you are doing".

Martin