From: Wincent Colaiuta <win@wincent.com>
Date: Thu, 19 Feb 2009 09:59:15 GMT
Subject: Re: git rebase -i
Message-ID: <2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com>
In-Reply-To: <43d8ce650902190155m4de23643r8a9d3c35686ea4e9@mail.gmail.com>

El 19/2/2009, a las 10:55, John Tapsell escribió:

> 2009/2/19 Wincent Colaiuta <win@wincent.com>:
>> 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.

That's exactly the problem. Most git users aren't going to expect "git  
rebase -i" to let you "rebase the last few commits".

Rebase is mostly used, talked about, and conceptualized in terms of  
rebasing onto other _branches_.

Cheers,
Wincent