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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 30 August 2017 at 12:11, Sebastian Schuberth <sschuberth@xxxxxxxxx> wrote:
> 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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux