Re: [PATCH 09/10] fast-export: allow seeding the anonymized mapping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> wrote:
> > Let's make it possible to seed the anonymization map. This lets users
> > either:
> > [...]
> > Signed-off-by: Jeff King <peff@xxxxxxxx>
> > ---
> > 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux