Jay Soffian venit, vidit, dixit 20.02.2009 01:26: > On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >>> $ git rebase -i -10 >>> $ git rebase -i -n -10 >> The syntax would certainly imply a different semantics from giving >> HEAD~10. How would you compute the set of commits to rebase sanely when >> you have merges after your 10th direct parent commit? > > I didn't mean to suggest that -10 and HEAD~10 are the same thing. > > I would expect -10 to act the same when given to rebase as it does > when given to format-patch. In both cases, you are asking the command > for a set of commits. > > But as I said, I don't exactly know what -10 means to format-patch if > there are merge commits because I've never tried to use it in such a > context. > > j. I guess it means exactly what git rev-list -10 HEAD means. And that would also be the easy way to implement it. BUT: The fact that it's not obvious what "-10" is in non-linear situations is the reason why it's probably not a good idea for r-b-i. If you want to rebase you need a clear picture of the revision graph. If you have one you know where to rebase from, and how to say so using HEAD~5 and such. If you don't have one then using an option like -10 could be dangerous. And in a linear situation, -10 is equivalent to HEAD~10 (+-1 ...). Michael -- 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
