Re: git rebase -i

From: Michael J Gruber <git@drmicha.warpmail.net>
Date: Feb 20, 2009, 11:02 UTC
Message-ID: <499E8DB9.5030505@drmicha.warpmail.net>
In-Reply-To: <76718490902191626u2202ed38xf63111b6a2758206@mail.gmail.com>

Jay Soffian venit, vidit, dixit 20.02.2009 01:26:

Show 19 quoted lines

> On Thu, Feb 19, 2009 at 7:11 PM, Junio C Hamano <gitster@pobox.com> 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