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

Björn Steinbrink [off-list ref] writes:

quoted

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