Re: git rebase -i

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

2009/2/19 Wincent Colaiuta [off-list ref]:

quoted

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

quoted

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