Re: [PATCH 3/3] fast-export: allow dumping the path mapping

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

 



On Fri, Jun 19, 2020 at 12:24:30PM -0700, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > When working with an anonymized repo, it can be useful to be able to
> > refer to particular paths. E.g., reproducing a bug with "git rev-list --
> > foo.c" in the original repo would need to replace "foo.c" with its
> > anonymized counterpart to produce the same effect.
> 
> That would not work with "git rev-list -- 'foo*'", where there is no
> counterpart, no?

Correct. There's no way that can work without treating the "foo" prefix
as a token and anonymizing it consistently. We currently only treat full
path components as tokens. So "foo/" will always be "ref123/", but
"foobar" will have no relation.

> It almost feels as if we want a separate knob to disable
> anonymization for paths and perhaps refs while still anonymizing the
> blob contents, or something like that.

I think such a knob could be useful for some situations, but I don't
think it's a complete replacement for a mapping dump, since you may not
want to reveal your pathnames (or refnames). Unlike refnames, where I
can easily point a tag "foo" at a commit of interest and then ask that
"foo" not be anonymized, pathnames are harder to change.

An alternative would be to let users seed the mapping (e.g., to ask that
"foo1" and "foo2" become "anon1" and "anon2"). That requires a little
more forethought on the part of the user, but it also avoids them having
to dig through the mapping to rewrite their commands (instead they use
the mappings they already invented).

-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