Jeremy Morton <ad...@game-point.net> writes: > But surely, it's recommended with Git that you try to avoid doing > --no-ff merges to avoid commit noise?
That is a misconception, I am afraid, coming from two different camps. Some projects do not want any merges for whatever reason, not limited to --no-ff merges. They want linear history perhaps due to inertia from their CVS days. In mergy projects, where no such "merge avesion" exists, there still is a valid reason why you are told to avoid no-ff, but I do not think it is primarily because no-ff is bad. The real reason why people need no-ff to record the fact that the "side branch" was a separate development is because they rebase on top of the project's tip right before they push it out. If you do not do that last minute rebase, you do not have to do a no-ff, unless the project is so quiet and no other people are actively working on the codebase. And in such a case, no-ff would be very much justified. I do not fundamentally oppose if you want to add "Done-as-part-of: frotz-topic" at the end of the log message of each commit that belongs to the topic in your project (I personally wouldn't welcome such a convention in _this_ project, though). Christian's "trailers" series may serve as a building block for such a feature. But as we can see in the thread, many people view (including me) that the choice of branch name is a personal thing, irrelevant in the project-wide history, so even if you add a built-in support to make it easier for you to add such a trailer, it has to be something optional the projects explicitly must choose to use by flipping some toggle. -- 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
