Björn Steinbrink:

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

quoted text
> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html