On 2009.11.05 19:09:48 -0600, Jonathan Nieder wrote:
> 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
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
--
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