Björn Steinbrink [off-list ref] writes:
"merge --squash" is one of the things I really dislike, because it turns
off the "history" part of the merge. You can say "Merging in git is about
histories, merging in svn is about changes only" to describe the major
difference for the merge commands in the two systems... "But then
there's --squash which turns git into svn".
I agree with this to some degree, but I do not offhand think of a better
alternative.
At the first sight, it looks as if what "merge --squash" does was
implemented as a new option "--squash" to the "merge" command merely
because the way _how_ it internally needs to compute the result was
already available in the implementation of "merge" command, and not
necessarily because _what_ it does was conceptually consistent with the
way "merge" works.
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".
On 2009.12.09 11:46:01 -0800, Junio C Hamano wrote:
Björn Steinbrink [off-list ref] writes:
quoted
"merge --squash" is one of the things I really dislike, because it turns
off the "history" part of the merge. You can say "Merging in git is about
histories, merging in svn is about changes only" to describe the major
difference for the merge commands in the two systems... "But then
there's --squash which turns git into svn".
I agree with this to some degree, but I do not offhand think of a better
alternative.
At the first sight, it looks as if what "merge --squash" does was
implemented as a new option "--squash" to the "merge" command merely
because the way _how_ it internally needs to compute the result was
already available in the implementation of "merge" command, and not
necessarily because _what_ it does was conceptually consistent with the
way "merge" works.
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, just like the "rebase --revisions"
proposal. "rebase" just happens to already provide the necessary
operations, but if cherry-pick would accepts ranges, this looks a lot
more logical to me:
git cherry-pick HEAD..that_branch
git reset --soft this_branch@{1} # [1]
git commit
[1] I assume that like "rebase", such a cherry-pick command would
already add a single reflog entry for the current branch
I cherry-pick all changes, and then use reset + commit to squash them
together to a single commit. To me, it's "I want to get all the changes
and squash them into a single commit", not "I want to squash the other
side's history in the background, without actually affecting the other
side and then merge that squashed version of the history".
So "cherry-pick --squash ..that_branch" seems more logical at the
conceptual level. Internally, it could of course just do a three-way
merge, instead of being stupid and repeating the "apply, commit --amend"
sequence over and over again.
Björn