git rebase stops on empty commits

git rebase stops on empty commits

[Mark Blakeney]

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

Re: git rebase stops on empty commits

[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.

Re: git rebase stops on empty commits

[Peter Krefting]

Mark Blakeney:

> but all the "git commit --allow-empty" commits are committed with my own 
> name and current date+time.

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 - http://www.softwolves.pp.se/

Re: git rebase stops on empty commits

[Mark Blakeney]

Peter Krefting <peter <at> softwolves.pp.se> writes:
> 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.

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.

Re: git rebase stops on empty commits

[Nanako Shiraishi]

Quoting Mark Blakeney <markb@berlios.de>

> 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.

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.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/

Re: git rebase stops on empty commits

[Mark Blakeney]

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.