Committer workflow

[Stephen J. Turnbull]

Michael Sperber writes:
 > 
 > "Stephen J. Turnbull" <stephen at xemacs.org> writes:
 > 
 > > What we should have done, I think, is to use a DAG-oriented VCS, 
 > 
 > Do you mean "use the VCS in a non-DAG-oriented manner"?  'Cause
 > Mercurial is a DAG-oriented VCS, and we're using it in a DAG-oriented
 > way.

By which you mean committers can pretend their line of development is
a straight line, and not worry about nodes, right?

It doesn't work so well for reviewers, though.

 > What you describe, if I understand correctly, would create a
 > linear patch history.

Yes.  That's the right thing to do for the reviewers, especially given
how strongly array-oriented Mercurial's UI is.  (Hint: show how to
retrieve the hash ID of the parent of a non-merge commit.)

 > We could do the exact same thing as "git rebase" with MQ, but it
 > has the problem (that it shares with "git rebase") that it doesn't
 > preserve patch identity.

By "preserve patch identity" you mean that the developer can work in a
single workspace, push his patch, and when he later pulls from the
public repo, not get a conflict.  Right?

That's a nice property, I agree.  But with a UI that made handling
named branches convenient, this wouldn't be a problem.  You just drop
the branch on the floor after you push its content, and pull that
right back in with your next update.