Feature: Renaming/removing files on the fly

[frej]

In #95 @atykhyy suggests a --filter-names flag along the lines of --filter-contents for a allowing files to be renamed and/or removed during conversion.

I'm open for suggestions, but do we really need a filter for this? Can we not just use a mapping file like we are using for authors and branch names? Do we want to extend the mapping file to support regexps with capture in order to easily rename files?

Regardless of the choice of filter or mapping file we also have to decide how this feature interacts with the --filter-contents and filename encoding conversion. Should --filter-names override the filename conversion or be applied before/after the filename is given to the content conversion filter?

[Himura2la]

Mapping files are better, because they explicitly define all actions and the result is predictable.
The most rock-solid way is mapping without any regexes or globs. The mapping can be like this:

"dir1/dir2"="dir1/Dir2"
"dir1/.git"=

The second line should remove the dir1/.git from history.
The first line will rename dir2 to Dir2. These are the two transformations I needed.

I also think that --filter-names is not the best name, maybe --filter-tree or --filter-files of --filter-paths?

I tend to filter contents after filtering names. It can be faster if some paths are cut out. And we need to explicitly state the order of application everywere we can.

[frej]

The most rock-solid way is mapping without any regexes. The mapping can be like this:

Agreed, if you want regexps you can always write a program that traversers the hg-repo and writes the mapping file for you. I the syntax is "file-to-remove"="" we can reuse the existing mapping file parser.

[Himura2la]

Empty string for deletion is less intuitive than no string at all, but if it's much easier, there should not be a problem.

[frej]

I don't feel strongly for either variant, so I guess it depends on the ambition level of the contributor :)