RFC: committer field in extras for applied patches

[Laurens Holst]

Op 30-03-11 04:27, Eric Eisner schreef:
> Hi,
>
> The motivation for this feature is from hg's repo: being able to see 
> who reviewed and committed a patch that was not committed by crew/mpm. 
> Other projects that accept a lot of patches via patchbomb would also 
> benefit. I'm mostly focusing on the semantics of when to add the 
> metadata, and ignoring for now how one would view it.
>
> Idea 1: patch only
> On import/qimport/qpush/qrefresh, if the patch has a different user 
> than ui.username(), add committer=username to extras.
>
> Idea 2: Every commit to the repo
> This would be implemented at a lower level, maybe in repo.commit. Any 
> time a supplied user is different from ui.username(), add 
> committer=username to extras.
> In addition to patch creation, the --user flag of commit/qrefresh will 
> create committer=ui.username(). This mostly seems pointless to me 
> though. This is pretty much the semantics of git for comparison.
>
> Thoughts?

This reminds me of the Mozilla pushlog. If the tree goes red 
(compilation error), actually it is the person who has push rights to 
the central repository who is responsible to fix it.

If you have a patch-oriented contribution process like Mercurial 
development has, this may be the same person as the committer. But when 
you pull changes from contributors it won’t be. What you really need to 
store is the source of the change; either the local committer or the 
person who pushed the change (or the pull url?).

Also adding this header as changeset meta-information would alter the 
changeset hash, I don’t like that either. If a patch is applied by 
someone else, right now the changesets are identical, it will recognise 
that you already have it and you can pull from that person without 
having to merge it with your original changeset.

So -1 from me.

Maybe it’s something that would be better handled by pushkeys?

~Laurens