[PATCH] convert: add --authormapsuffix to append set text to author names (issue4171)
Mads Kiilerich
mads at kiilerich.com
Thu Feb 13 19:52:56 CST 2014
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
More information about the Mercurial-devel
mailing list