> How often is this desired, when the merge is clean? Well, if I could quote your own words: >> I use "git pull . topicA topicB" for a tetrapus, so that is not >> a reason for me, but when a topicA's older parts are worthy to >> be in 'next' while later parts are not yet, I often do (on 'next'): >> >> git merge "Merge early part of branch 'topicA'" HEAD topicA~3 I can't speak from personal experience, but a merge can bring in a lot of changes, and sometimes the auto-generated message doesn't say quite as much as you'd like. The commits on the branch speak for themselves, of course, but sometimes it's nice to add the same sort of overview that appears in a [PATCH 0/13] e-mail. We wouldn't have that convention if there wasn't a frequent desire for it. (Indeed, it might be nice to come up with a way of including a piece of the "please pull" e-mail, similar to the way that git-applypatch works.) > If the answer is "not so often", you can already use "commit > --amend" after "pull" creates an automated merge commit. It's not done very often right now, but how much of that is due to the awkwardness? I agree it works perfectly, but "commit --amend" has very much the feel of a workaround. I'm not going to besiege Troy for a decade over the idea, but it seemed worthwhile. I just found git-merge's innards a little bit intimidating. - 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