Re: Emacs Bazaar repository

[David Allouche]

On Fri, Mar 14, 2008 at 3:30 PM, Andreas Schwab <address@hidden> wrote:
> Matthieu Moy <address@hidden> writes:
>
>  > As opposed to that, bzr makes the distinction between "mainline
>  > revisions" (that you commited in the branch), and merged revisions
>  > (ancestors of merge commits that you brought here with a merge).
>
>  Is that a useful distinction?  I think git treats all branches equal,
>  there is no "mainline".

Bzr also treats all branches as equal. There is no "mainline branch"
the tool knows of. But there are "mainline revisions" in the ancestry
of a given revision (or branch tip).

>  If you merge two branches that touch different
>  parts of the tree there is no need to distinguish the two threads.

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.

It gives a better view of the intent of the committer. For example, a
revision with the message "merge from trunk" usually means "take in
whatever got in the trunk", not "merge feature a, bugfix b, cleanup c,
refactoring d, and 43 other equally crucial changes". Most merges do
not reflect essential work that occured on the branch.

On the other hand, the mainline commits usually capture the essential
work that occured on a branch. By distinguishing them, bzr makes it
easier to read the history of a branch.

>  > That's a real difference in the way git and bzr deal with the history
>  > DAG, not just about "log". For example, git merge defaults to
>  > fast-forward (i.e. if you merge a revision you are a direct ancestor
>  > of, you just jump to that revision without creating a new commit).
>
>  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.

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.