On Oct 6, 6:02 pm, Junio C Hamano <gits...@xxxxxxxxx> wrote: > Others commented on the current practices and gave their own useful tips > already, but an additional hint is to name your branch more sensibly, so > that you do not feel it is useless to record it in the history. While I can see your point of view, I don't think that it fits every work-flow. In particular, if you want to maintain a linear history on the master branch but record the completion of a feature as a commit object separate from the last patch in a series, you have two choices at the moment: 1. A fast-forward merge, followed by an empty commit with --allow- empty. However, the empty commit seems to get discarded on merges, or finds other ways to disappear outside of the feature branch on which it was created. It probably isn't a bug, but it can be very surprising to create an empty commit object on a feature branch, and then have it disappear when you merge to master. 2. A merge commit with an explicit merge message, which is what we've been talking about in this thread. The point of the exercise is (mostly) to integrate with issue trackers like Pivotal or GitHub, where a commit with certain keywords can integrate with ticket history. But, IMHO, it doesn't necessarily make sense that any given patch closes a ticket; sometimes they do, but sometimes I really prefer a standalone commit to essentially say "and now the ticket is really, really done." The fact that there have been so many useful suggestions about how to work around this issue seems to imply that it isn't a low bus-factor issue. My personal vote is for your suggestion of an [-e|--edit] flag for the merge; that would make it (mostly) consistent with commit's behavior. I can certainly see that in the common case the default merge message is the right thing to do, but I really do feel that there ought to be *some* flag to allow a visual editor to edit the merge message without having to amend the merge commit or merge without a commit just so that the next commit will invoke the editor. Ultimately, I guess what I'm really agitating for is just an editor option for merge commits. If you take work-flow out of the equation, isn't there still a case for easily-editable merge messages? -- 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