Re: git rebase -i

From: John Tapsell <johnflux@gmail.com>
Date: Feb 19, 2009, 09:55 UTC
Message-ID: <43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com>
In-Reply-To: <A3E3A7A0-F03F-4C8B-B3F8-756B0E89798C@wincent.com>

2009/2/19 Wincent Colaiuta <win@wincent.com>:

Show 20 quoted lines

> El 19/2/2009, a las 10:21, John Tapsell escribió:
>
>> Hi,
>>
>>  I often do   'git rebase -i HEAD~10'  to rebase.  Since afaics it
>> doesn't matter if you go back 'too far' I just always use HEAD~10 even
>> if it's just for the last or so commit.
>>
>>  Would there be any objections to making  'git rebase -i' default to
>> HEAD~10  or maybe 16 or 20.
>
> Sounds awfully arbitrary and counter-intuitive to me.
>
> Take a sample of Git users who know what "git rebase" does and ask them what
> they intuitively think "git rebase -i" without any additional arguments
> should do; I'd be _extremely_ surprised if they answered that it should
> default to HEAD~10, HEAD~16, HEAD~20, or HEAD~N for any N.
>
> (I could tell you what my intuition tells me, but I don't think it's very
> interesting.)

It doesn't really matter if the user manages to guess what the number N is, just that it's "recent commits".

If a sample of git users would expect "git rebase -i" to let you rebase the last few commits, then it doesn't really matter all that much what N is. 10 seems a reasonable default as any.

John