Re: git rebase -i

From: Wincent Colaiuta <win@wincent.com>
Date: Feb 19, 2009, 10:15 UTC
Message-ID: <6887C6DB-E9C8-4DC8-BD1E-C20E92271FA5@wincent.com>
In-Reply-To: <20090219101154.GB16119@coredump.intra.peff.net>

El 19/2/2009, a las 11:11, Jeff King escribió:

Show 23 quoted lines

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

Yes, I do the same. But notice that you did "git rebase -i -- 
 >>>origin<<<---". Seems to me you are definitely _thinking_ in terms  
of your topic _branch_ and not in terms of "the last few commits".

Cheers, Wincent