Committer workflow

[Stephen J. Turnbull]

Michael Sperber writes:

 > - It doesn't work for longer-lived branches like Carbon, where things
 >   are resynchronized multiple times.

Of course not.  I'm not proposing that Carbon be synchronized by
rebasing.

 > - It doesn't solve the problem I believe you're seeing, namely that the
 >   patch you reviewed isn't the patch that gets committed.  "server-side
 >   git rebase" would be prone to breaking to build automatically, because
 >   "no conflicts" doesn't mean that that merge was actually correct.

G'wan.  That's true of Mercurial merges too.  In fact, Mercurial
merges are theoretically suspicious because they cross changeset
boundaries.  At least they used to, and the documentation brags about
this fact.

On the other hand, since instead of matching final text to final text,
git rebase actually applies a sequence of patches, I think it's
probably less susceptible to the no-conflicts-broken-merge syndrome.

 > - If you don't to server-side rebasing, you impose an undue burden on
 >   the developers who keep rebasing their patches.

The flip side is that the merge turds are a burden imposed on
reviewers by people who measure their status in number of commits.  I
have very little sympathy for committers who regularly forego the
overhead of compiling their creations complaining about the overhead
of one "hg pull -u" per commit.

As for the developers who actually do rebasing, well, I'll continue
rebasing.  You'll only ever find that first merge turd from me;
rebasing is not a burden on me, or Didier.  Probably not on Jerry.

 > - I agree things are different when there's a single integrators, like
 >   Linus.  We don't.

Red herring.  Nobody is talking about that.  We're talking about the
conflict between the interests of commit-oriented developers and the
interests of review-oriented developers.

 > The most natural way of doing business with Mercurial and, I
 > conjecture, git, is to do it the way we are doing it, and that
 > means making explicit what revision a developer started from when
 > making changes.

Well, that's not obvious.  There are a lot of people who believe that
a change that takes long enough to develop that rebasing (in the sense
of doing "hg pull -u" before editing and committing) doesn't work well
should not be simply a temporally-ordered brain dump into the common
sewer, but rather *composed* as a coherent changeset.

I'm not going to make any wild claims that that's "most natural".  But
as you know I think that what XEmacs needs is more well-thought-out
and documented refactoring, and less of the kind of "paint-over-the-
cracks" activity that a cheap-commit policy enables.

 > However, for small, one-off patches, I'd have no objection to
 > stating a policy that asks developers to push on top when possible,
 > and give them instructions on how to get there using Mercurial
 > Queues.

Queues is overkill for small one-off patches IMHO.  Just do a quick
"hg pull -u" before editing.  At least at current levels of code churn
that should do a fine job of reducing merge turds well below my
tolerance level.