On 2009.12.10 09:20:28 -0800, Junio C Hamano wrote: > Björn Steinbrink <B.Steinbrink@xxxxxx> writes: > > >> But at the conceptual level, "merge --squash" is a short-hand for this > >> command sequence: > >> > >> git rebase -i HEAD that-branch > >> ... make everything except the first one into "squash" > >> git checkout - ;# come back to the original branch > >> git merge that-branch ;# fast forward to it > >> > >> So after all, it is "merge it after squashing them". > > > > To me, that approach looks backwards,... > > Yes, of course, but what you are missing (and I am at blame for forgetting > to mention the history behind this in the message you are responding to) > is that "merge --squash" to support a particular need/use case was done > way before "rebase -i" came into existence. Hm? You started explaining that "merge --squash" would be right because you can do it via some command sequence that involves rebase -i and then merge. I said that using that rebase+merge sequence as an argument for the choice of the name is wrong. It would even have made more sense to me if you said: git merge that-branch git reset --soft HEAD^ git commit -C ORIG_HEAD Which is "merge, but then drop the extra parents", which pretty close to what "merge --squash" does (and that sequence even gets it right not to rewrite that-branch). I'm not arguing that you shouldn't have chosen "merge --squash" to do that. You couldn't possibly foresee the future and that git might get rebase -i or maybe at some day cherry-pick -i <range>. I'm just saying that in retrospective, it's sad that merge doesn't always mean "merge histories", but that --squash makes it degenerate to "merge changes". I don't see why you're trying to defend the choice of "merge --squash" using a IMHO rather weird command sequence that happens to involve "merge", using commands that weren't present when "merge --squash" was added, but at the same ignore the "cherry-pick -i <range>" command git might learn in the near future, which allows for a much saner explanation: git cherry-pick -i ..that-branch ... make everything except the first one into "squash" And given that, one could add a --squash flag to cherry-pick that makes it do the "squash everything" itself, allowing it to be a bit smarter about the whole thing, because it could use a three-way merge internally, instead of cherry-picking all the individual commits. Making "git cherry-pick --squash ..that-branch" the same as "git merge --squash that-branch". > A nicer workflow may be to use "rebase -i" to clean up the history before > even contemplating to integrate the topic to the mainline, instead of the > above "abandoning or forking off again", if you know today's git. Well, I'm not saying that git should completely lose the abilitiy to do something like "merge --squash", just that if it learns "git cherry-pick <range>", it might as well get the --squash thing for cherry-pick, maybe allowing for "merge --squash" to be phased out. And heck, having it as an option to cherry-pick instead of merge would probably already help a lot to make people realise that it won't remember that the changes got "integrated". We've had people on #git that wondered why repeated "git merge --squash" commands would try to merge the same stuff over and over again, leading to the same conflicts every time. Because they didn't realise that with --squash, "git merge" is no longer about merging histories. > But interactive was not available back then. It was introduced at 1b1dce4 > (Teach rebase an interactive mode, 2007-06-25), which is 1 year after > 7d0c688 (git-merge --squash, 2006-06-23). Again, I'm not blaming you for having chosen that command back then. Just saying that it might be better to have the same functionality in an extended cherry-pick now. 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