Björn Steinbrink wrote: > For example in git.git, I can do "git log --first-parent > ..origin/master" to get a high-level log of what happened. And then I > might see commit b7eb912b0, which is "Merge branch ja/fetch-doc". So I > know "OK, there were some doc updates", without having to crawl through > the individual commits. Yep, fast-forward merges do ruin the --first-parent log. Thanks for the reminder. >> Of course, these things are a matter of taste. I just wanted to >> explain why a fast-forward could at least sometimes be the right >> result from merging a topic branch (and why, in practice, some people >> never end up needing to use --no-ff). > > Sure, fast-forwards can be the right thing, e.g. when you have a > (possibly useless) branch head "master" that you update by pulling. In > such a case merge commits would only lead to useless clutter. I hope this use case becomes less important as git’s UI improves. To track unmodified upstream sources, a simple 'git checkout' to get up-to-date is much simpler, except that "git branch" does not display the current branch any more. Using 'git pull' for the daily update makes for a distractingly merge-heavy history once one has commits of one’s own. A similar use case won’t disappear: asking someone else to resolve a merge for you and pulling the result. For both these tasks, --ff-only might give better behavior. In other cases, I would guess some people would always want --no-ff and others never. Apparently, there is a configuration option to support this: add a line "mergeoptions = --no-ff" (or "mergeoptions = --ff") to a [branch "master"] section in .git/config or ~/.gitconfig. > But > Richard wants to see where topic branches got merged (to be still able > to see what got merged in the future), and yeah, that's a matter of > taste. But you argued that using --no-ff would "[miss] some of the main > benefits of feature branches", which is simply not true. I spoke imprecisely; I should have said that if most merges are candidates for fast-forwarding, this suggests feature branches are not being used in the best way, and --no-ff just makes that situation more tolerable. Then your response pushed me towards the question of whether --no-ff is a good idea in general, and I got distracted. :) Sorry for the confusion, and thanks for the insights. Regards, Jonathan -- 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