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