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

From: Jeff King <peff@peff.net>
Date: Jun 22, 2020, 21:38 UTC
Message-ID: <20200622213813.GC1376217@coredump.intra.peff.net>
In-Reply-To: <xmqqr1uahn9t.fsf@gitster.c.googlers.com>

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

Show 9 quoted lines

> Jeff King <peff@peff.net> 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