Hi, On Wed, 30 Apr 2008, Dmitry Potapov wrote: > On Wed, Apr 30, 2008 at 09:47:02AM +0100, Johannes Schindelin wrote: > > > > I cannot bring myself to feel that this is messy. The more I think about > > it, the clearer it becomes for me that the pick call should use the > > original commit, whereas the merge call should use the rewritten commit > > (and should therefore only be called when all ancestors of that merge > > which need rebasing were rebased already). > > > > Maybe, it would be better if re-written commits were marked a bit > differently, so there will be no confusion about whether an original or > re-written commit is referred. For instance, re-written commits can be > marked by adding apostrophe at the end, so if the original commit was > "abcdef" then the re-written should be called as "abcdef'". At least, it > will make plain clear for anyone where in merge rewritten commits are > mentioned. Otherwise, it looks too magical to me. Fair enough. (For the "too magical" part.) But it would break down if you picked one commit twice, in order to split it. OTOH, this is a rare thing, and you really only need to refer to rewritten commits in the "reset" and "merge" commands. But there is a bigger problem with what you suggest: When merging a commit that is _not_ in the rewritten part of the history, adding an apostrophe is actively wrong. And I still believe strongly that a regular "rebase -i -p" user will not want to refer to original commits, except for the "pick" command. 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
