From: Jeff King <peff@peff.net>
Date: Tue, 23 Jun 2020 18:35:25 GMT
Subject: Re: [PATCH 09/10] fast-export: allow seeding the anonymized mapping
Message-ID: <20200623183525.GB1444619@coredump.intra.peff.net>
In-Reply-To: <CAPig+cQ1EGR6_8NJ+U3MQEseU1yT9k_AwdL8Mg7qZAB8Ev4y3g@mail.gmail.com>

On Tue, Jun 23, 2020 at 02:11:51PM -0400, Eric Sunshine wrote:

> On Tue, Jun 23, 2020 at 11:25 AM Jeff King <peff@peff.net> wrote:
> > Let's make it possible to seed the anonymization map. This lets users
> > either:
> > [...]
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> > diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt
> > @@ -119,6 +119,11 @@ by keeping the marks the same across runs.
> > +--seed-anonymized=<from>[:<to>]::
> > +       Convert token `<from>` to `<to>` in the anonymized output. If
> > +       `<to>` is omitted, map `<from>` to itself (i.e., do not
> > +       anonymize it). See the section on `ANONYMIZING` below.
> 
> By the way (possible bikeshedding ahead), "seed anonymous" seems
> overly technical. I wonder if a name such as
> '--anonymize-to=<from>[:<to>]' might be clearer and easier for people
> to understand.

I wrestled with the name, and I agree "seed" is overly technical. And I
came up with many similar variations of "anonymize-to", but they all
seemed ambiguous (e.g., it could be "to" a file that we're storing the
data in).

Perhaps "--anonymize-map" would be less technical?

> In fact, in an earlier email, I asked whether --seed-anonymized should
> imply --anonymize. Thinking further on this, I wonder if we even need
> the second option name. It should be possible to overload the existing
> --anonymize to handle all functions. For instance:
> 
>     '--anonymize' would anonymize everything
> 
>     '--anonymize=<from>[:<to>]' would anonymize and map <from> to <to>
> 
> So, the example you give in the documentation would become:
> 
>     git fast-export --all \
>         --anonymize=foo.c:secret.c \
>         --anonymize=mybranch >stream
> 
> Or is that too cryptic?

Yeah, that was another one I considered, but it both seemed cryptic
(after all, we're saying what _not_ to anonymize), and it squats on the
"anonymize" option. So imagine we had another option later, like
"anonymize blobs and paths, but not refs", that could easily be
"--anonymize=blobs,path" or "--anonymize=!refs". I'd rather not paint
ourselves in a corner.

-Peff