Emacs Bazaar repository

[Stephen J. Turnbull]

BTW, I should admit that this discussion is pretty academic to me: I'm
committed to git for reasons not mentioned in this thread.  That is,
the basic git data structure looks like a Lisp list.  Nor do I care to
convert anybody to git.  I am just interested in how VCSes, including
bzr specifically, work, and what kinds of workflow bzr supports well.

I also do not want to see you and Emacs screw up by having Emacs
commit to bzr for purely political reasons, and then be very unhappy
that they did.  I suggest to you that it is *really* important to bzr
to make sure Emacs is happy it chose bzr.

Matthieu Moy writes:

 > "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.

Well, yes, I know that; you guys have been quite good about reminding
us in every post.  But I don't care if I have to run different
commands to see the different presentations; I don't need the combined
bzr-log-style presentation.

 > > 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.

I wish you would explain this stuff a little more algorithmically.  I
have no idea what you mean.  "Branches" don't break things, commits
do.  "Commits on branches" do break things, but only on that branch.
And things *will* get broken and need to be repaired afterward, it's
not a question of "permit".  So to make sense of what you wrote, there
must be some merging activity going on, but which to what and when?

 > 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.

Nonsense.  I can think of at least two ways to do it, one involving
tags and the other emulating bzr's default behavior (see below for
corrected, slightly unclean, version).

 > branch. As opposed to that, in the git community, fixes done after
 > submitting a merge request are usually done by rewritting history.

Yes.  But you've got the cart before the horse.  git is what it is
because that is Linus's preferred workflow.  If Linus wanted the bzr
style, it can surely be easily implemented on top of git's plumbing.

And you should be careful about using terms like "rewrite history".
In git that only happens when the user explicitly invokes `git-gc
--prune'.  What you describe is an edit of the table of contents of
the history book, not of history.  The original history is still
there using git-fsck, it is just much less convenient to access.

 > > True.  You can get exactly the same effect with git.  I *think*
 > >
 > > git fetch branch-to-merge
 > > git merge --strategy=ours FETCH_HEAD
 > 
 > >From man git-merge:

OK.  Not only did I totally forget that --strategy=ours will ignore
the other heads, but you're right, it's just not possible with the
bundled porcelain up to 1.5.4.4 (my version).  I thought "d'oh, I got
it backwards, just a regular merge should DTRT", like this

git tag tmp-tag
git pull branch-to-merge
git branch tmp-branch                   # still on master!
git reset --hard tmp-tag
git merge tmp-branch

would do the trick, but git-merge detects the fast-forward and
enforces the same result as git-pull.  You need to do something like

git checkout -b tmp-branch
git pull branch-to-merge                # assume fast-forward
git commit-tree `git-write-tree` -p $this-branch -p $tmp-branch > .git/refs/heads/this-branch

(The '$'s mean I think you have to dereference this-branch and
tmp-branch explicitly, git-commit-tree is probably too low-level to do
it for you.  And yes, I checked it in an example; it works, and in
gitk produces a remarkably bzr-log-like summary.)  So yes, it's
unclean that I have to resort to plumbing, but once again it's easy
enough to do, eminently scriptable, and the "unclean" expedient
reflects Linus's taste in workflow, not a deficiency in git's design.