Re: Preserving branches after merging on ancestor

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 6, 2009, 05:03 UTC
Message-ID: <20091106050353.GA8824@progeny.tock>
In-Reply-To: <20091106021038.GA27206@atjola.homenet>

Björn Steinbrink wrote:

Show 5 quoted lines

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

Show 8 quoted lines

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

Show 5 quoted lines

> 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