On 2009.12.09 14:20:23 +0100, Peter Krefting wrote: > Björn Steinbrink: > > >Err, no. "git merge --squash foo" merges all changes from the > >merge base of HEAD and foo up to foo. "git cherry-pick foo" takes > >just the changes > > from foo^ to foo. > > Exactly! > > What I meant to say in the original message was that conceptually, > the difference between a "git rebase --reverse A..B", a "git > cherry-pick A..B" and a "git merge --squash A..B" is minute. > > And when continuing the thought experiment, the step from "git merge > --squash A..B" to "git merge A..B" is not very large either, just (a > lot) more difficult to implement. "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. Implementing probably wouldn't be that hard, IIRC it should be a matter of messing with the fake merge base that cherry-pick uses to get its job done. While "git cherry-pick foo" uses foo^ as the merge base, you'd just make "git merge --squash A..B" work like "git cherry-pick B" but use A as the fake merge base. It's been a while since I looked at the cherry-pick code though, so I might be off here. (Kind of ironic though that I didn't think of that when I said that "cherry-pick --squash" would be hard to do...) 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. Björn -- 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