Re: git-rebase eats empty commits

From: Stephan Beyer <s-beyer@gmx.net>
Date: Jul 12, 2008, 22:12 UTC
Message-ID: <20080712221207.GB22323@leksak.fem-net>
In-Reply-To: <g4vrrm$g35$1@ger.gmane.org>

Hi,

Michael J Gruber wrote:

Show 8 quoted lines

> "git commit" allows empty commits with the "--allow-empty" option, i.e.  
> commits which introduce no change at all. This is sometimes useful for  
> keeping a log of untracked work related to tracked content.
>
> "git rebase" removes empty commits, for the good reason that rebasing  
> may make certain commits obsolete; but I don't want that in the case  
> mentioned above. Is there any way to specify "--preserve-empty" or 
> similar?

First I can speak for git-sequencer: there is no such thing as a "preserve empty" option, but currently, when you are picking a commit that has already been applied so that no changes occur, it will pause. (It will not pause if it is a fast-forward.) Yet, I was unsure if this is a "correct" behavior, but it seemed to be useful, because you can inspect the situation.

In my mind, the same should happen with an empty commit, so I tested it:
 1. It pauses.
 2. In that pause I only need to run "git commit --allow-empty" and I have
    the picked empty patch with that commit message.

So if this behavior is kept, there is no such need for such an option.

Now I'm checking it with the old rebase-i (I'm always referring to git-rebase--interactive as rebase-i) and exactly the same behavior occurs.

But rebase is not rebase-i. So I've also checked both, pure rebase and rebase-m: then the empty commit is lost.

To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty" and then "git rebase --continue" and you have what you want.

Regards,
  Stephan

-- 
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F