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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Sunshine <sunshine@xxxxxxxxxxxxxx> writes:

> On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]