Björn Steinbrink <B.Steinbrink@xxxxxx> writes:
>> 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).
--
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