RFC: committer field in extras for applied patches

Eric Eisner ede at mit.edu
Tue Mar 29 22:45:09 CDT 2011


On Tue, Mar 29, 2011 at 23:13, Matt Mackall <mpm at selenic.com> wrote:

> On Tue, 2011-03-29 at 22:27 -0400, Eric Eisner wrote:
> > 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.
>
> The git converter has always implemented this by adding
>
> committer: foo
>
> at the bottom of commits.


While this solution is currently more accessible to the end user, an
official key in extras would enable useful things like revsets:
hg log -r 'user(mpm) or committer(mpm)'

While this could be implemented by parsing the commit message, that doesn't
seem very robust.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110329/303e3138/attachment.htm>


More information about the Mercurial-devel mailing list