From: Jeff King <peff@peff.net>
Date: Thu, 19 Feb 2009 10:11:54 GMT
Subject: Re: git rebase -i
Message-ID: <20090219101154.GB16119@coredump.intra.peff.net>
In-Reply-To: <2A7CAA9F-DB42-4782-BF61-41E8DA577DF2@wincent.com>

On Thu, Feb 19, 2009 at 10:59:15AM +0100, Wincent Colaiuta wrote:

>> 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_.

Actually, I don't think that's true anymore with "rebase -i"; it is
probably most convenient way in core git to rewrite the history of a
patchset. E.g., a core part of my workflow as a contributor is:

  $ git checkout -b jk/topic origin
  $ while true; do hack hack hack; commit commit commit; done
  $ git rebase -i origin

which gives me a list of everything on the topic, ready to be
reordered, squashed, or edited as appropriate.

-Peff