On Wed, Mar 10, 2010 at 2:13 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html