On 2009.12.09 11:46:01 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@xxxxxx> 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".
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
--
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