Re: Preserving branches after merging on ancestor

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Nov 6, 2009, 01:09 UTC
Message-ID: <20091106010947.GB4425@progeny.tock>
In-Reply-To: <20091105232848.GA1939@atjola.homenet>

Björn Steinbrink wrote:

> I guess Richard took the "branch topic1, merge topic1, branch topic2,
> merge topic2" thing just as an example because that ends up with two
> fast-forwards.

Hmm, I found Richard’s example pretty realistic. I used to work like that, and I don’t think I am the only one.

> And your example _still_ has such a fast-forward.

Yep, if you really want to avoid fast-forwards, please use "--no-ff"!

But what I was trying to make clear was that in some workflows, the fast-forwards are not so harmful. They even make the history a little cleaner (easier to read and understand).

Show 19 quoted lines

> Instead of:
> 
> A---B---C---D---E (topic2) (master)
>      \
>       F---G---H (topic1)
> 
> He wants:
> 
>       F---G---H (topic1)
>      /
> A---B-----------M (master)
>      \         /
>       C---D---E (topic2)
> 
> So he can see at which point topic2 got merged. This allows to ask "which
> commits got merged here" (and for a merge-once topic branch this means:
> Which commits are related to that topic), by using for example:
> 
> git log M^1..M^2 # Will show C, D and E

You can get the same information locally even with a fast-forward:

git log master@{1}..master

But to someone reading the published history, it is not available. Depending on your way of working, this may or may not be reasonable.

Perhaps your merge commit messages contain important information about the branch’s overall purpose and provenance, which would be impossible if there is no merge commit.

On the other hand, if the goal is just to present the fact of a merge, to explain where a patch falls in the larger scheme of things, then how large a chunk of changes I decided to call a feature does not seem too important.

Imagine a patch series, cleaning up some ugly code that has been bothering me for a while:

 base [master] --- A --- B --- C [cleanup]

It looks good, so I merge to master with --no-ff.

 base --------- D [master]
     \         /
      A---B---C [cleanup]

Looking at that code inspires me to build a new feature that is much easier with the cleaned up version. So I fork a branch from cleanup (Or master? Their content is the same, but somehow I choose one) and write some patches for the new feature.

 base --------- D [master]
     \         /
      A---B---C [cleanup] --- E --- F --- G

It looks good, so I merge.

 base --------- D --------- H [master]
     \         /           /
      A---B---C---E---F---G

Is this really any easier to read than base---A---B---C---E---F---G? In hindsight, was this logically really two series, or is the D commit extra cruft?

Almost always, a fast-forward comes from a continuation of this kind, since that is what it means for a commit to be the logical commit to fork from.

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

Regards, Jonathan