El 19/2/2009, a las 10:55, John Tapsell escribió:
2009/2/19 Wincent Colaiuta <win@xxxxxxxxxxx>:
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
--
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
