Emacs Bazaar repository

[Stephen J. Turnbull]

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.  In git it
typically falls out of repeated use of get-rebase, in branches where
one might care about it.

I don't see in this feature a good reason to accept the horrible
asymptotic behavior we're seeing from "bzr log" in the emacs bzr repo.

Another thing that worries me about the performance we're seeing is
that since CVS doesn't keep merge information at all, what we are
probably seeing is a tree, not a general DAG, in the emacs bzr repo.
There simply shouldn't be any interesting sorting to be done.

 > >  If you just move forward in the history it is not really a merge, so
 > >  there should not be a need for creating a marker for it.
 > 
 > You can do fast forward in bzr with "pull". Merge behave differently
 > because we consider that "merge" _as a task_ has a different meaning
 > _to the user_ than pull.
 >
 > 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).

 > 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

is the way to do it.