Hi, On Wed, 23 Aug 2017, Stephan Beyer wrote:
> On 08/23/2017 01:08 AM, Stefan Beller wrote: > > The editor opened proposing the following instruction sheet, > > which in my opinion is buggy: > > > > pick 1234 some commit > > exec make > > pick 2345 another commit > > exec make > > pick 3456 third commit > > # pick 4567 empty commit > > exec make > > pick 5678 yet another commit > > exec make > > This reminds me of another bug I stumbled over recently regarding empty > commits. > > Do this: > # repo preparation: > git init > :> file1 > git add file1 > git commit -m "add file1" > :> file2 > git add file2 > git commit -m "add file2" > > # the bug: > git checkout -b to-be-rebased master^ > git commit --allow-empty -m "empty commit" > git rebase -i master > > It says "Nothing to do". > Unsurprisingly, the problem persists when you apply other empty commits: > > git commit --allow-empty -m "another empty commit" > git rebase -i master > > Adding a "real" commit solves the problem: > > :>file3 > git add file3 > git commit -m "add file3" > > Adding further empty commits is no problem: > > git commit --allow-empty -m "yet another empty commit" > > So the problem seems to be that rebase -i (like rebase without -i) > considers "empty commits" as commits to be ignored. However, when using > rebase -i one expects that you can include the empty commit... > > Also, the behavior is odd. When I only have empty commits, a "git rebase > master" works as expected like a "git reset --hard master" but "git > rebase -i" does nothing. > > The expected behavior would be that the editor shows up with a > git-rebase-todo like: > # pick 3d0f6c49 empty commit > # pick bbbc5941 another empty commit > noop These days, I reflexively type `rebase -ki` instead of `rebase -i`. Maybe you want to do that, too? Ciao, Dscho
