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

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.12.10 09:20:28 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> 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.

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