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

On 2009.12.10 09:20:28 -0800, Junio C Hamano wrote:

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

quoted

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.

Hm? You started explaining that "merge --squash" would be right because
you can do it via some command sequence that involves rebase -i and then
merge. I said that using that rebase+merge sequence as an argument for
the choice of the name is wrong. It would even have made more sense to
me if you said:

git merge that-branch
git reset --soft HEAD^
git commit -C ORIG_HEAD

Which is "merge, but then drop the extra parents", which pretty close to
what "merge --squash" does (and that sequence even gets it right not to
rewrite that-branch).

I'm not arguing that you shouldn't have chosen "merge --squash" to do
that. You couldn't possibly foresee the future and that git might get
rebase -i or maybe at some day cherry-pick -i <range>. I'm just saying
that in retrospective, it's sad that merge doesn't always mean "merge
histories", but that --squash makes it degenerate to "merge changes".

I don't see why you're trying to defend the choice of "merge --squash"
using a IMHO rather weird command sequence that happens to involve
"merge", using commands that weren't present when "merge --squash" was
added, but at the same ignore the "cherry-pick -i <range>" command git
might learn in the near future, which allows for a much saner
explanation:

git cherry-pick -i ..that-branch
... make everything except the first one into "squash"

And given that, one could add a --squash flag to cherry-pick that makes
it do the "squash everything" itself, allowing it to be a bit smarter
about the whole thing, because it could use a three-way merge
internally, instead of cherry-picking all the individual commits. Making
"git cherry-pick --squash ..that-branch" the same as "git merge --squash
that-branch".

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.  

Well, I'm not saying that git should completely lose the abilitiy to do
something like "merge --squash", just that if it learns "git cherry-pick
<range>", it might as well get the --squash thing for cherry-pick, maybe
allowing for "merge --squash" to be phased out. And heck, having it as
an option to cherry-pick instead of merge would probably already help a
lot to make people realise that it won't remember that the changes got
"integrated". We've had people on #git that wondered why repeated "git
merge --squash" commands would try to merge the same stuff over and over
again, leading to the same conflicts every time. Because they didn't
realise that with --squash, "git merge" is no longer about merging
histories.

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

Again, I'm not blaming you for having chosen that command back then.
Just saying that it might be better to have the same functionality in an
extended cherry-pick now.

Björn