Committer workflow [was: commit: Fix specifier inheritance behavior]

[Stephen J. Turnbull]

Didier Verna writes:

 >   That's exactly why I recommend in Patcher's doc to avoid that
 > situation [== failed push followed by merge].  I'm actually
 > wondering if it's a good thing at all to perform such commits to
 > the main repo. My current policy is to ensure that my copy of the
 > repository is up to date, and then patch and commit right away so
 > as to avoid the need for merging.

I work this way too.  But this is an annoying, CVS-like way to work.
And I see no easy way to enforce it (see below, however).

 > Doing things the way you describe feels wrong to me because you're
 > typically introducing information that is local to *you* into the
 > main repo: nobody else is interested in the fact that you committed
 > in an out-of-date copy of the main repo, and "fixed" this later on
 > by merging.

Working that way is what most people consider the main advantage of
modern VCSes, and Mercurial is designed to make it especially easy.

What we should have done, I think, is to use a DAG-oriented VCS, I'll
use git below because it makes sense to me, and had a commit hook that
automatically rebases.  Then the workflow in the usual case would be

committer$   git push my-topic-branch:temp-branch
commit-hook$ git rebase --onto master master temp-branch
commit-hook$ git diff -r master -r temp-branch | send-commit-notice
commit-hook$ git checkout master
commit-hook$ git pull . temp-branch
commit-hook$ git branch -D temp-branch

and in the conflict case

committer$   git push my-topic-branch:temp-branch
commit-hook$ git rebase --onto master master temp-branch
commit-hook$ git rebase --abort
commit-hook$ echo "Try, try again!" | send-commit-notice
commit-hook$ git branch -D temp-branch

At times of low code churn, this would work pretty much as currently,
except that we'd automatically get sane commit notices, and there
would be no merge turds in the public history (all of the pulls would
be fast-forwards by construction).

At times of high code churn, people who did the rebasing locally would
have a big advantage in getting their stuff safely committed.