Re: [PATCH RFC] rebase: add --revisions flag

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 10, 2009, 17:20 UTC
Message-ID: <7vpr6mkaoz.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20091210074358.GA7723@atjola.homenet>

Björn Steinbrink <B.Steinbrink@gmx.de> writes:

Show 11 quoted lines

>> But at the conceptual level, "merge --squash" is a short-hand for this
>> command sequence:
>> 
>>     git rebase -i HEAD that-branch
>>     ... make everything except the first one into "squash"
>>     git checkout - ;# come back to the original branch
>>     git merge that-branch ;# fast forward to it
>> 
>> So after all, it is "merge it after squashing them".
>
> To me, that approach looks backwards,...

Yes, of course, but what you are missing (and I am at blame for forgetting to mention the history behind this in the message you are responding to) is that "merge --squash" to support a particular need/use case was done way before "rebase -i" came into existence.

Here is how "merge --squash" is explained in the log message:

    git-merge --squash
    
    Some people tend to do many little commits on a topic branch,
    recording all the trials and errors, and when the topic is
    reasonably cooked well, would want to record the net effect of
    the series as one commit on top of the mainline, removing the
    cruft from the history.  The topic is then abandoned or forked
    off again from that point at the mainline.

A nicer workflow may be to use "rebase -i" to clean up the history before even contemplating to integrate the topic to the mainline, instead of the above "abandoning or forking off again", if you know today's git.

But interactive was not available back then. It was introduced at 1b1dce4 (Teach rebase an interactive mode, 2007-06-25), which is 1 year after 7d0c688 (git-merge --squash, 2006-06-23).