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