Committer workflow

[Martin Buchholz]

I rather like the model that no one gets to push to other peoples'
repositories, people only pull.  I think that's how Linus works.  His
"trusted lieutenants" let him know when they would like him to pull,
and he does.... but presumably first into an "incoming"
private-to-Linus repository that he can peruse before pulling into his
public-for-export repository.  I also rather like keeping the revision
history in the important repositories "clean", which may mean forcing
or strongly encouraging other people to throw away their patch
development histories.

I rather like the idea that a subsystem repository can keep more
history than a "master" repository.  Not every developer needs to have
the entire history of the project in their own repository at all
times.

In a world where a project might have a thousand separate
repositories, one quickly gets to the point where almost all
changesets are trivial merge changesets, polluting the history.

I don't know why you refer to the Linux model as "single integrator".
I see it as rather the opposite -- Linus encourages multiple
specialized trees, each with their own integrator.

Martin

>>>>> "M" == Michael Sperber <sperber at deinprogramm.de> writes:

M> "Stephen J. Turnbull" <stephen at xemacs.org> writes:

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

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

M> The problem is that it just doesn't scale, in various ways:

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

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

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

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

M> The most natural way of doing business with Mercurial and, I conjecture,
M> git, is to do it the way we are doing it, and that means making explicit
M> what revision a developer started from when making changes.  However,
M> for small, one-off patches, I'd have no objection to stating a policy
M> that asks developers to push on top when possible, and give them
M> instructions on how to get there using Mercurial Queues.

M> -- 
M> Cheers =8-} Mike
M> Friede, Völkerverständigung und überhaupt blabla

M> _______________________________________________
M> XEmacs-Patches mailing list
M> XEmacs-Patches at xemacs.org
M> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches