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

From: Peter Krefting <peter@softwolves.pp.se>
Date: Dec 10, 2009, 08:43 UTC
Message-ID: <alpine.DEB.2.00.0912100937580.22606@ds9.cixit.se>
In-Reply-To: <20091209134133.GA30596@atjola.homenet>

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

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.

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

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

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

-- 
\\// Peter - http://www.softwolves.pp.se/