Re: Preserving branches after merging on ancestor

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.

quoted

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