Emacs Bazaar repository

[Matthieu Moy]

"Stephen J. Turnbull" <turnbull at sk.tsukuba.ac.jp> writes:

> BTW, I should admit that this discussion is pretty academic to me: I'm
> committed to git for reasons not mentioned in this thread.

It case it's unclear, I'm also using mostly git for my works.

> Matthieu Moy writes:
>  > > 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 explained it with an example which you striped. I can't do better. I
can try to do worse if you want:

Developer A branches from branch B.

Then, developer A commits something in his branch, say, "C", which
introduces a bug, and prevents the testsuite from passing.

In a new commit, developer A fixes the bug.

Then, this branch is merged into B.

The question is :

Is the fact that the commit "C", which doesn't pass the testsuite, be
reachable from the head of branch B a problem. Is it acceptable in
your flow.

In the flow pushed by Git, it's not. Because Git takes great care to
avoid treating the first parent as special. In bzr, it's different,
because bzr _does_ consider the first parent as special.

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

Well, if you prefer, replace "branch" with "commit in a branch" in my
sentence, but that's really playing with words.

> And you should be careful about using terms like "rewrite history".

Tell that to the git developers, then. If they agree with you, they'll
change the wording used in their own documentation. Untill then, I'll
use the same wording as git does.

> 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

Sure, or upgrade git and use --no-ff. But you have to make sure you
never ever run any command which may do a fast-forward, or your
history will seem totally screwed-up if you care about the first
parent. Then, you can probably implement something to view just the
first parent in git log. That just doesn't fit in the git philosophy.

> the "unclean" expedient reflects Linus's taste in workflow, not a
> deficiency in git's design.

Where did I mention a deficiency in git's design flow?

Do I need to cite myself?

>> Both approaches have advantages, but none is perfect.

The Git guys did it this way because they think it's the best way to
go, and they have good reasons for it.

-- 
Matthieu