Re: Committer workflow
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(a)deinprogramm.de> writes:
M> "Stephen J. Turnbull" <stephen(a)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(a)xemacs.org
M> http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches