Re: git-rebase -i prunes commits with empty commit-message

From: Erik Faye-Lund <kusmabite@googlemail.com>
Date: Mar 10, 2010, 13:34 UTC
Message-ID: <40aa078e1003100534j189eef5kd60855f80e9dd626@mail.gmail.com>
In-Reply-To: <4B979AEF.5010201@alum.mit.edu>

On Wed, Mar 10, 2010 at 2:13 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Show 20 quoted lines

> Erik Faye-Lund wrote:
>> I'm in the process of converting an SVN repo to Git, and in the
>> process I found one quite disturbing feature of
>> git-rebase--interactive.sh: It discards commits with empty commit
>> messages!
>>
>> Here's a recepie for reproducing the issue:
>> --->8---
>> git init
>> git commit -m "dummy" --allow-empty
>> git commit -m "dummy" --allow-empty
>> git commit -m "dummy" --allow-empty
>> git filter-branch -f --msg-filter 'sed -e "s/dummy//"'
>> git rebase -i HEAD~2
>> --->8---
>
> Does git really claim to handle commits with empty commit messages?
> That you have to use git-filter-branch to create the test case suggests
> that the answer is "no", but I don't know.  (git-commit, for example,
> refuses to create a commit with an empty message.)

If git didn't, I'd expect it to be impossible to create them. This was
just a minimal example on how to reproduce it, and it's a silly
use-case. I think my original way of getting into the state was a tad
more legitimate:
1) I had an SVN-repo with empty commit-messages
2) I imported that SVN-repo into git through git-svn, and git-svn
appended it's meta-data to the otherwise empty commit-message.
3) I used git-filter-branch to remove the git-svn metadata (as the
git-filter-branch man-page suggest)

I don't know what happens when git-svn encounter empty commit-messages with the --no-metadata option enabled. In my case, the decision to fully migrate the repo to Git (instead of just using git-svn as a nicer svn-frontend) came long after 1) and 2) were done.

> If indeed git requires commit messages to be non-empty, then the fault
> here seemingly lies with git-filter-branch for allowing commit messages
> to be completely deleted.

If there is some decided-upon restriction that commit-messages cannot be empty, then I agree with you.

From experiments, it seems that git-commit does not seem to allow empty commit-messages. But I can't find this documented. I'm not sure what git-commit-tree allows, but I think it should deny creating commits with empty messages (possibly unless some option is given) if there should be a restriction, because most scripts use this to generate commits AFAIK.

But to be honest, it seems to me like in this precise instance it's probably better to just fix git-rebase--interactive.sh. There's no good reason for it to barf on the commits -- especially since noon-interactive rebase handles them just fine. Unless someone screams out loud, I might take a stab at it when I get time.

-- 
Erik "kusma" Faye-Lund