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

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

On 2009.12.09 14:20:23 +0100, Peter Krefting wrote:
> Björn Steinbrink:
> 
> >Err, no. "git merge --squash foo" merges all changes from the
> >merge base of HEAD and foo up to foo. "git cherry-pick foo" takes
> >just the changes
> > from foo^ to foo.
> 
> Exactly!
> 
> What I meant to say in the original message was that conceptually,
> the difference between a "git rebase --reverse A..B", a "git
> cherry-pick A..B" and a "git merge --squash A..B" is minute.
> 
> And when continuing the thought experiment, the step from "git merge
> --squash A..B" to "git merge A..B" is not very large either, just (a
> lot) more difficult to implement.

"git merge" is about merging histories. --squash and the A..B you
suggest make it degenerate into merging changes (and you can't record
that using the commit DAG). So that messes things up conceptually.

Implementing probably wouldn't be that hard, IIRC it should be a matter
of messing with the fake merge base that cherry-pick uses to get its job
done. While "git cherry-pick foo" uses foo^ as the merge base, you'd
just make "git merge --squash A..B" work like "git cherry-pick B" but
use A as the fake merge base. It's been a while since I looked at the
cherry-pick code though, so I might be off here.

(Kind of ironic though that I didn't think of that when I said that
"cherry-pick --squash" would be hard to do...)

Anyway, "git merge" with a range simply makes no sense at all given how
git's merge works (opposed to svn's idea of merging, which is about
changes, not about histories). If you want a squash flag, tell
cherry-pick to handle ranges and teach such a flag to it.

Björn