Setting extra fields at commit time (i.e. adding an --extra flag to the commit command)

[Angel Ezquerra]

On Tue, Mar 4, 2014 at 9:07 AM, Angel Ezquerra <angel.ezquerra at gmail.com> wrote:
> Hi,
>
> I find myself on the unfortunate position of having to find a way to
> have mercurial co-exist with Microsoft's TFS. I have made a small
> python script that is able to "pull" from TFS into a mercurial
> repository. It does so by creating commits in a local mercurial
> repository that correspond to the TFS revisions.
>
> This works fine, but I think I should record the original TFS revision
> id on the mercurial commit. I can do so by putting the information on
> the commit message itself, but I'd like to also store that info in a
> more formal way. I thought that the best place to do so would be to
> add an entry on the extra revision field. This would let me use the
> extra revsets function to find the commits that were imported from
> TFS, for example.
>
> The problem is that there is no way through the mercurial command line
> to set entries in the extra dict. I could create a proper mercurial
> extension rather than a simple script that calls the mercurial command
> line instead but that has a couple of drawbacks:
>
> 1. I would now need to update the extension as mercurial evolves
> (which is why we usually recommend that people use the mercurial
> command line if they can).
> 2. I would have to call repo.commit, but commands.commit does a few
> additional things (such as handling amend, etc).
>
> I may end up doing this anyway, but I wonder if it would not be a good
> idea to allow setting the extra field through the commit command
> interface. The riskiest part is that giving unfettered access to that
> field may interfere with existing uses of the extra field. Instead
> perhaps we could create a "user namespace" within the extra field,
> that is left for users to use (e.g. any extra fields passed to the
> commit message would have their name automatically prepended with
> "user.")
>
> Regarding the interface for this new feature we could add an --extra
> flag to the commit command. Ideally the user could specify --extra
> multiple times to set multiple extra user fields, but I don't think
> that is possible with the current mercurial command line specification
> syntax. An alternative would be to accept a dict-like or json-like
> syntax for the extra field. For example:
>
>     hg commit -n "test" --extra "'field1': 'This is my first user
> field', 'field2': 'This is a second user field'"
>
> This would add two extra fields called 'user.field1' and
> 'user.field2'. A user could refer to then through a revset such as
> "extra(user.field1)", etc. This syntax is a little heavy and ugly, but
> I don't think that would be a huge problem for the kind of users that
> would use this.
>
> What do you guys think?
>
> Angel

I just realized that it is define a a command flag that can be called
multiple times (by setting its default value to []). So the example in
my proposal could be simplified to:

    hg commit -n "test" --extra "field1: This is my first user field"
--extra "field2: This is a second user field'"

Which is much nicer and easier to handle.

Angel