Re: Committer workflow
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.
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches