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

[Mads Kiilerich]

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.)

> # 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?

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

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.

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.

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.

/Mads