git rebase stops on empty commits

I am new to git but think I have found a bug. I searched the git archives and found the same issue reported by Michael Gruber about 1 year ago but it was discounted by Stephan Beyer and the problem seems to be forgotten about.

See http://kerneltrap.org/mailarchive/git/2008/7/8/2388804

In short, I think git rebase needs a "--allow-empty" option. I have git repo which I converted from an old system and which for various reasons requires me to --allow-empty commits when I build it. The repo has about 3300 commits but now when I try to fix up some of the early commit comments using git rebase -i I find I have to manually sit at the terminal and dumbly type;

    git commit --allow-empty (then quit out of editor)
    git rebase --continue

ad nauseum for all the many empty commits ...

I'm only rebasing to change some commit messages which must be a trivial git operation. Surely git rebase -i should be able to be told to continue through empty commits itself? At the very least some kind of message to the user would help - I only found that git commit --allow-empty works around this rebase problem once I found the old post above.

I am using the latest version 1.6.3.3 of git. This is the version used to build the repo from scratch and for the git rebase -i etc.

-- Mark Blakeney

Actually, further to this I have more justification why this can be considered a bug.

After performing the "git rebase -i" I find that all the "git commit --amend" edits are correctly committed with the original commit author and date+time etc but all the "git commit --allow-empty" commits are committed with my own name and current date+time.

Mark Blakeney:

If you edit the commit, you claim ownership of it. You should probably try using the -C option to commit, it should allow you to edit the message, while keeping the authorship and timestamp intact.

Peter Krefting <peter <at> softwolves.pp.se> writes:

Thanks Peter, that works well. E.g.

    % git rebase --continue
    Finished one cherry-pick.
    # Not currently on any branch.
    nothing to commit (working directory clean)
    Could not apply c33a375... Stop LNCC until OPC connection
    % git commit --allow-empty -C c33a375
    [detached HEAD e7d66f4] Stop LNCC until OPC connection
    % git rebase --continue
    ....

So rebase can actually do what I want but my fundamental issue remains. I said "pick" in the rebase for all of these commits but rebase is forcing me to do each one manually! And it requires some rather arcane git magic that could only be procured from a guru on a mailing list. :)

Surely something like an option --allow-empty on the rebase -i to skip over these no-brainer picks is trivial to implement - and makes sense? As a simple user, and knowing the original commits required --allow-empty, it was the first option I went looking for on the rebase -i when I encountered this problem.

Quoting Mark Blakeney <markb@berlios.de>

I think an alternative is to use 'git rebase --skip'. I don't understand why you can't get rid of the commits that don't do anything and serve no purpose once and for all.

In your first message you only said 'for various reasons' and it isn't clear why you need such empty commits. Often people say they want to add a comment about the state of the tree with empty commits, but tags are designed for that purpose. Unlike some other systems a tag can have a message of its own.

Because these particular original commits were real commits ported from our previous archaic system which for technical reasons have lost the actual file changes (although they are trivial for each of these particular cases). But all our commit comments are very verbose and valuable, specifically in these cases, so it would be a shame to lose them from the linear change history.

Anyway, the question of why anybody would want empty commits is beside the main point. The fact is that git provides this option so my bug sugestion here is that git rebase does not cater for this existing git commit option very well. My contention is that "git commit" supports --allow-empty so "git rebase" should as well.