programming reddit: "Bazaar blows goats"
Stephen J. Turnbull
stephen at xemacs.org
Fri Dec 11 04:12:08 GMT 2009
Gordon Tyler writes:
> Forgive me for not wanting to trawl through the emacs-devel archives,
> but why do they consider it evil?
Because the merge commit contains no interesting information, and is
potentially inefficient. If you have
B C |\
this history: |/ and merge to B C you still need to test D, etc.
If you think of C as a "real" revision, you should test it. You don't
get any real informational benefit from merging. There's very little
new information: you already know that D is different from B, so the
only thing you find out from the full history with explicit merge is
that the developer of C started from A, not B. This is uninteresting,
and completely useless in the case of a trivial merge.
So some people disagree, but many prefer rebasing to B C, testing
C' (and not C), and then throwing away the unpublished branch leading
to C. I think everybody acknowledges that with "many" commits on
either branch, there are strong arguments that merging provides better
information in the history, but those who have smoked the (f)rebase
crack are unlikely to ever concede that merge-per-real-commit
histories have any redeeming features. Note that as my diagrams
suggest, rebase *is* a merge. The argument is that knowing that it's
a merge is spuriously precise; there is no improvement in the accuracy
of the history presented.
N.B. My trees grow up the page, as Mother Nature designed them. :-)
More information about the bazaar