[PATCH V2] graft: record the user who performed the command in the extras dictionary

Gregory Szorc gregory.szorc at gmail.com
Fri Apr 10 21:50:33 CDT 2015


On Fri, Apr 10, 2015 at 9:25 PM, Matt Harbison <mharbison72 at gmail.com>
wrote:

> # HG changeset patch
> # User Matt Harbison <matt_harbison at yahoo.com>
> # Date 1428713353 14400
> #      Fri Apr 10 20:49:13 2015 -0400
> # Node ID 7f973c288b98f4f0a8d974c475bf9a042b7f9975
> # Parent  553dc2b094d9e1eb2f66ba8f1ec36ecb55cf9d64
> graft: record the user who performed the command in the extras dictionary
>
> Similar to the username stored with an obsolete marker, this comes only
> from the
> configured username or environment (i.e. -u is ignored).  While not
> unspoofable,
> it should help provide additional forensic detail, without requiring the
> developer to remember to specify -U.  It's also not clear that overwriting
> the
> author attribute is appropriate in all environments.
>
> Since there might be some automated systems that don't have a username
> configured, just skip adding the field if it isn't available instead of
> aborting.
>

I like the intent of this patch but I'm not a fan of "graft-user." I think
answering "who was the last person to 'touch' this commit" is useful beyond
graft and I could see us doing something similar for other history editing
commands (e.g. rebase).

Thinking ahead to when we want this metadata exposed to users (think a
template keyword), I'd rather we have a single entity, not N, to represent
"last touched by user." "last-user?"

I do like how "graft-user" is expressive. Normally I don't argue for
dropping potentially useful metadata. I could probably be assuaged if there
were a single template keyword that extracted at most 1 *-user extra. But
what if there are multiple entries? Maybe "last-user" + rich obsolescence
markers is sufficient after all...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150410/97608bc8/attachment.html>


More information about the Mercurial-devel mailing list