[PATCH] convert: add --authormapsuffix to append set text to author names (issue4171)

Lawrence Stewart lstewart at room52.net
Thu Feb 13 21:57:20 CST 2014

Hi Mads,

On 02/14/14 12:52, Mads Kiilerich wrote:
> On 02/14/2014 01:30 AM, lstewart at room52.net wrote:
>> # HG changeset patch
>> # User lstewart
> (Yeah - you don't use the username configuration convention most
> Mercurial users use and that Mercurial and the documentation more or
> less recommends. That proves that the use case is somewhat valid.)


I have a bunch of projects I use Mercurial for and often configure my
username pref in the repository's hgrc file rather than my ~/.hgrc such
that it only applies to that project. I obviously forgot to do it for my
checkout of the official Mercurial repo which I've been hacking in.

>> # Date 1392337372 -39600
>> #      Fri Feb 14 11:22:52 2014 +1100
>> # Node ID 2b6fdac02ea3ae0fdefa8d0738f7df679a80dcfd
>> # Parent  80628d4069be724089ea487a300d62f4cbd8970d
>> convert: add --authormapsuffix to append set text to author names
>> (issue4171)
>> The --authormap option to convert does not provide a mechanism to
>> template how
>> author names should be mapped from the source to destination
>> repository. In the
>> absence of a more complete templating like feature, this new option
>> allows some
>> set text to be appended to every author name during the conversion.
>> This is
>> particularly useful for changing project-local usernames into globally
>> distinguishable author identifiers e.g. by mapping "lstewart" ->
>> "lstewart at FreeBSD.org", without first having to obtain a list of all
>> authors in
>> the source repository and create an authormap from that list.
>> If --authormapsuffix is used concurrently with --authormap, the suffix is
>> appended to post-authormap-translated names as well as
>> non-authormap-translated
>> names.
> You mention the lack of a more complete templating like feature. How
> could it look like? Could we aim at that instead?

We certainly could and probably should. Only reason I proposed this
patch is that it exists now, works as advertised and I've been using it
during my setup of http://hg-beta.freebsd.org/ (currently offline for
another few hours while I rerun the conversion with my --authormapsuffix
patch so that authors are mapped to @FreeBSD.org so that downstream
consumers of the repo can better differentiate from changes made by
upstream authors vs local authors).

> Convert has a big pile of hacks. I can be blamed for some of them. All
> of the hacks made sense and solved a real problem ... but together they
> have made convert far from "elegant". Tagmap is the latest example. I
> don't think adding more options and features necessarily makes convert
> better or more useful.
> By now it has been proven that there are valid use cases for changing
> almost anything while converting. But should we continue to add an
> infinite number of options, one by one? It seems like what we are
> missing is:
> * a framework (or documentation?) for easy mangling of changesets with
> Python snippets while converting
> * as one example of that, a more generic configurable framework that can
> apply 'mapfiles' or regexps too all kind of changeset properties

Indeed, that sounds like a good path forward and pretty much the sort of
thing I had in mind when I referred to a templating system in the bug

> Some inspiration could come from existing functionality such as
> authormap and branchmap and tagmap, the hg transplant --filter option,
> hooks, subpaths ... and postfix lookup tables and???
> This use case could perhaps be solved with configuration like
> convert.ini:
> [author]
> # default is regexp like subpaths
> (.*)$ = \1 at FreeBSD.org
> # "mapfile" is reserved and can be used to implement --authormap:
> # mapfile = FILE
> used as
> hg convert --filter=convert.ini ...
> or
> mangle.py:
> class mysource(hgext.convert.hg.mercurial_source):
>     def getcommit(rev):
>         c = hgext.convert.hg.mercurial_source.getcommit(rev)
>         c.author = c.author + '@FreeBSD.org'
>         return c
> used as
> hg convert --source-type=mangle.py:mysource ...
> - or something like that. The syntax examples are just quickly made up,
> but it seems like they also could solve other valid use cases ... such
> as tagmap.

As an off-the-cuff first stab at things, the above seems like a good
starting point to me and on the right track.

> Back to authormapsuffix:
> In this specific case it wouldn't be hard to make a first run to get a
> list of authors, generate a authormap with a bit of scripting, and just
> use that.

So the problem with that (and the reason I hacked up this patch) is I'm
running a continual conversion against the FreeBSD svn source every 15
mins, and the only way to make the above robust is to regenerate the
authormap before every sync. Otherwise, when new committers join the
project they won't be in the authormap and would fail to get mapped to

The --authormapsuffix appends to any authorname encountered so I never
run the risk of an unsuffixed authorname making it into the Hg repo.

> Other equally valid kinds of author rewriting would still either require
> their own option ... or could be solved with the same generic method.
> The needs that could come next could be domain renaming or
> adding/removing full names ... or exceptions for those who already
> configured with domain.


> I am thus a bit reluctant to recommend this patch. Technically it is
> fine, but from a product management perspective it adds compatibility
> constraints and doesn't move us in an obviously right direction.

I would be happy to be engaged with the templating system project we're
discussing, but don't have sufficient cycles to take it on by myself or
to be the primary driver of the project.

As for the patch at hand, I'm willing to accept dev crew consensus on
whether putting it in now is worthwhile or not. My general feeling is a
bird in the hand that works and addresses a straight forward use case is
worth having with an understanding there is a longer term goal to move
to the flexible templating system.


More information about the Mercurial-devel mailing list