Re: git-rebase eats empty commits

From: Stephan Beyer <s-beyer@gmx.net>
Date: Jul 15, 2008, 20:19 UTC
Message-ID: <20080715201902.GC6244@leksak.fem-net>
In-Reply-To: <g5fpnm$3jb$1@ger.gmane.org>

Hi,

Michael J Gruber wrote:

Show 6 quoted lines

> Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
>> 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.
>
> I assume this is with git from master? With git 1.5.6.2 rebase -i  
> doesn't stop there, not even when I change "pick" to "edit"!

Hmm, in fact this is with my git from Debian, from master and my sequencer-based one:

	$ /usr/bin/git --version
	git version 1.5.6
	$ ./git --version
	git version 1.5.6.3.350.g6c11a
	$ git --version
	git version 1.5.6.3.506.g902dd

And, btw, the reason of this behavior is no special case in rebase-i, it's just that git-cherry-pick fails (exit status != 0), if you pick an empty commit (and then rebase-i will pause because of conflict). And *this* is because builtin-revert.c runs git-commit without --allow-empty. This has never changed, so I cannot believe that the behavior changed in any version of git. Or I am missing a point.

	$ git cherry-pick empty		# empty is an empty commit tagged as "empty"
	Already uptodate!
	Finished one cherry-pick.
	# Not currently on any branch.
	# Untracked files:
	[...]
	nothing added to commit but untracked files present (use "git add" to track)
	$ echo $?
	1
	$ EDITOR=touch git commit --allow-empty
	Created commit 145f1d0: empty

The same happens when doing rebase -i instead of cherry-pick.

Regards,
  Stephan

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