Jeremy Morton <ad...@game-point.net> writes: > On 28/04/2014 09:32, Felipe Contreras wrote: >>>> some people to is to always merge with --no-ff, that way you see the branch >>>> name in the merge commit. >>> >>> But surely, it's recommended with Git that you try to avoid doing >>> --no-ff merges to avoid commit noise? >> >> Nope. Different people have different needs, there's no recommendation. If >> anything, the recommendation is to do a ff merge, because that's the default. > > That's what I'm saying. With an ff merge, you don't get the merge > commit message telling you the branch name.
And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. I don't want to have people tell me when submitting patches "but can't you give this a better branch name?" and then have to use git filter-branch or whatever else to get the branch name removed. > As I said before, I usually consider my branch names useful > information worth keeping around - I'm not sure why you don't. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? This is not a useful part of a commit. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
