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

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

On 2009.12.10 09:43:51 +0100, Peter Krefting wrote:
> Björn Steinbrink:
> >"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.
> 
> I know, this is the one "feature" of CVS that I sometimes miss in
> Git, that I cannot "merge" just parts of a history, and have that
> recorded in the history tree. I know it's wrong, I know I could do
> it better, but sometimes it's the shortcut that would make life
> easier for me. :-)

Hm, does CVS really record the fact that things were merged? I've never
seriously used CVS, so I have no idea... And if it does, is it just the
same thing as the svn "merge"-tracking?

> But the reason I mentioned it was because of the discussion on
> whether the "reverse rebase" should be an option to "cherry-pick" or
> not, and I mentioned that it could just as well be "merge" since it
> can be used to throw away history as well.

OK, and I disagreed because I think that "merge --squash" is already
wrong. And given your comment below about retiring "merge --squash", I
guess we're in agreement now, right?

> >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.
> 
> And tell "merge" to tell me that if I try, so that if I try
> 
>   $ git merge A..B
> 
> I would get a message saying something like
> 
>   Cannot merge a range of commits. Try "git cherry-pick A..B" or
>   "git rebase --reverse A..B".

Hm, for an error message that "range of commits" is probably on the edge
of being confusing. After all "git merge B" will create a new commit M
that "says" that M^1..M^2 was merged to M^1. But I can't come up with a
better error message either.

> And perhaps we could also in the same way retire --squash?
> 
>   $ git merge --squash B
>   The "--squash" option is obsolete. Please use "git cherry-pick
>   --squash B".

git cherry-pick --squash ..B # Not just B itself, but the whole range

> (with a transition period where it would just call the other). Or
> whatever the options to simulate the old behaviour would be. This
> would make it clearer that "merge" preserves history while
> "cherry-pick" and "rebase" do not.

I'd certainly like that.

Bjoern