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