Re: [PATCH 2/3] rebase: accept -<number> as another way of saying HEAD~<number>

[Michael Haggerty <mhagger@alum.mit.edu>]

On 03/02/2014 04:55 PM, Matthieu Moy wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> 
>> On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
>>>> This is "rev-list style", where people can do "git rev-list -3" in
>>>> addition to "git rev-list HEAD~3". A lot of commands are driven by the
>>>> revision machinery and also accept this form. This addition to rebase
>>>> is just for convenience.
>>>
>>> I'm seeing some pretty strange results with this. If I use -1, -2, or
>>> -3 then it rebases the expected commits, however, -4 gives me 9
>>> commits, and -5 rebases 35 commits. Am I misunderstanding how this
>>> works?
>>
>> Nevermind. I wasn't paying attention to the fact that I was attempting
>> to rebase merges.
> 
> Your remark is actually interesting. Most (all?) Git commands taking
> -<n> as parameters act on n commits, regardless of merges.
> 
> So, this commit creates an inconsistency between e.g. "git log -3" (show
> last 3 commits) and "git rebase -3" (rebase up to HEAD~3, but there may
> be more commits in case there are merges).
> 
> I don't have a better proposal, but at least the inconsistancy should be
> documented (e.g. "note that this is different from what other commands
> like 'git log' do when used with a -<number> option since ..." in the
> manpage).

This might be a reason that "-NUM" is a bad idea.

Or perhaps "-NUM" should fail with an error message if any of the last
NUM commits are merges.  In that restricted scenario (which probably
accounts for 99% of rebases), "-NUM" is equivalent to "HEAD~NUM".

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/