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
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
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