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

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Dec 11, 2009, 11:07 UTC
Message-ID: <20091211110720.GA19232@atjola.homenet>
In-Reply-To: <7vpr6mkaoz.fsf@alter.siamese.dyndns.org>

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

Show 18 quoted lines

> 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