Re: Committer workflow
"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.
The problem is that it just doesn't scale, in various ways:
- It doesn't work for longer-lived branches like Carbon, where things
are resynchronized multiple times.
- 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.
- If you don't to server-side rebasing, you impose an undue burden on
the developers who keep rebasing their patches.
- I agree things are different when there's a single integrators, like
Linus. We don't.
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. 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.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
_______________________________________________
XEmacs-Patches mailing list
XEmacs-Patches(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches