Emacs Bazaar repository

Matthieu Moy Matthieu.Moy at imag.fr
Mon Mar 17 10:35:11 GMT 2008

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

> Removing emacs-devel per RMS's request.
> David Allouche writes:
>  > In bzr, the mainline ancestry of a revision is the transitive closure
>  > of the leftmost parent. The mainline ancestry is considered important
>  > because it records the sequence of commits that occured on a given
>  > branch.
> Which you can get from Mercurial with hg --follow-first.

"hg --follow-first" is only a part of what "bzr log" does: it _only_
follows the first parent. "bzr log" shows you the first parent, and
the merged revisions indented below.

>  > Typically, a gatekeeper only merges, then run the test suite, and only
>  > commit if the test suite pass. The gatekeeper's branch mainline
>  > history will only contain revisions that passed the test suite.
> In git, if the test suite doesn't pass on the gatekeeper's branch, he
> simply does "git reset --hard tag" (or perhaps resets to the last
> commit that passes, if the test is being run commit by commit).

That's a different thing.

The question is whether or not you allow a branch to temporarily break
something, and to repair it afterwards.

If you allow such thing, then the property you want to ensure is that
each revision reachable by following the first parent of upstream
passes the testsuite. In bzr, that means each mainline revision (shown
unindented) must pass the testsuite. In git, you can hardly do such
thing. Since the merge defaults to fast-forward, the path following
the first parent is pointless most of the time.

For example, suppose upstream has

X: stable release.

A contributor clones and implements something :

X+2: fix bug B.
X+1: implement feature A (introduces bug B)
X: stable release.

Then, upstream merges. In bzr, you'll see

43: merged feature A
    42.2: fix bug B.
    42.1: implement feature A (introduces bug B)
42: stable release

in git, you'll get

abc0123: fix bug B.
def4567: implement feature A (introduces bug B)
0123abc: stable release

And you don't guarantee that the path following the first parent
passes the testsuite at each step.

And this has an impact on the way people write code. Look at the bzr
history, you'll find tons of fixes for problems introduced earlier in
the same topic branch. In the bzr community, fixes done after
submitting a merge request are usually done on top of the submission
branch. As opposed to that, in the git community, fixes done after
submitting a merge request are usually done by rewritting history. The
idea is that each commit, not just the one in "mainline" should be

Take an example :

revno: 3283
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Sun 2008-03-16 02:26:32 +0000
  (Andrew Bennetts) Fix some LockableFiles warnings from test_smart.
    revno: 3194.1.3
      Change "that that" to just "that".
    revno: 3194.1.1
      Fix one LockableFiles warning from test_smart.py

Revision 3194.1.3 fixes a typo introduced earlier in 3194.1.1.

Had the same senario occured in the Git development, the author would
have rewond his private branch to 3194.1.1, "git commit --anotate"-ed
the patch to remove the typo, rebased the rest of the branch on top of
it, and re-submitted the result for a merge.

You can see that in the way people submit their work also: Git users
usually submit (small-)patch series, while bzr people submit a
collapsed diff.

Both approaches have advantages, but none is perfect.

>  > The way you make it sound, the git approach is "if we can get the same
>  > result by fast forward, we do not need a new commit". The bzr approach
>  > is that a new commit provides important historical information
>  > regardless.
> True.  You can get exactly the same effect with git.  I *think*
> git fetch branch-to-merge
> git merge --strategy=ours FETCH_HEAD

More information about the bazaar mailing list