Hi, On Thu, 15 Jan 2009, Junio C Hamano wrote: > (2) making completely unrelated commits on top of the state "edit" gave > you; this inserts a new commit in the sequence. > > (3) first "reset HEAD^", commit selected parts of the difference in one > commit, commit the reaminder in another commit; this splits the > commit the machinery just picked into two. > > By the way, "rebase --continue" codepath has extra code that does > something magical when the index does not match the HEAD commit. I > suspect what it does makes sense only in the originally intended usage > sequence (i.e. "edit" stops, you want to do "commit --amend" and then > "rebase --continue" but somehow you forgot to commit everything). > > How well does that logic work when the user wanted to do (2) or (3) above, > and happened to have the index unclean when s/he said "rebase --continue"? > Does it do something nonsensical? AFAICT the special handling is the only sane way to cope with (2) and (3), if it is the special handling that I am talking about: If the current HEAD differs with the HEAD just after dropping to the shell, rebase --continue will _not_ just commit with the recorded information and continue. The intended effect is that when you split a commit and continue with uncommitted changes, it will not just go ahead and call an editor with the original commit message: this message is now likely wrong. It will only call an editor with the original message as a convenience when you did changes, but did not commit at all before continuing. Just a convenience I found quite useful. Ciao, Dscho -- 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
