Re: Preserving branches after merging on ancestor

On 2009.11.05 19:09:48 -0600, Jonathan Nieder wrote:

Björn Steinbrink wrote:

quoted

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.

quoted

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

quoted

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

And after two weeks, you'll dig through the reflog to find the right
entries? Come on... And (as you said yourself below) everyone else
(including yourself in a different clone of that repo) doesn't have that
reflog entry anyway.

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.

The actual commits that make up the topic should have descriptive enough
commit messages to make extra "why merge this" messages shouldn't be
required. But merge commits provide a way of giving a high-level
overview of the history of a project.

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.

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.

And if I decide that for _this_ topic, I care to see what got merged, I
can do: git log b7eb912b0^1..b7eb912b0^2

Had this been a fast-forward, even the --first-parent history would
throw the individual commits at me, giving me less of a high-level
overview.

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?

Choosing "cleanup" as the starting point for an unrelated topic branch
(after all "cleanup" was already merged, so there's absolutely no reason
to base a new topic on it) is wrong. That history looks as if E,F,G was
a second part of the same topic branch.

I'd have done:

              E---F---G (topic2)
             /         \
0-----------D-----------H (master)
 \         /
  A---B---C (cleanup)

And then I could do "git log --first-parent master" to see H and D
(high-level view), and "git log H^1..H^2" or "git log D^1..D^2" to get a
low-level view at the merged topics.

Neither of which I could do with "0---A---B---C---E---F---G". With that,
I'd have to manually looking up the start/end points of each topic.

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.

Hm? I don't get that one. The "continuation" would be that you started
the second topic branch from the first topic branch, right? And that
caused the merge to "master" _not_ to be a fast-forward. So I'm somewhat
confused there.

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

Björn