Hi, Michael J Gruber wrote: > 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@xxxxxxx>, PGP 0x6EDDD207FCC5040F -- 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
