Re: [RFC PATCH] fast-export, fast-import: Let tags specify an internal name

[Elijah Newren <newren@gmail.com>]

On Wed, Apr 21, 2021 at 1:19 AM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Tue, Apr 20 2021, Junio C Hamano wrote:
>
> > Luke Shumaker <lukeshu@lukeshu.com> writes:
> >
> >> That'd work fine if they're lightweight tags, but if they're annotated
> >> tags, then after the rename the internal name in the tag object
> >> (`v0.0.1`) is now different than the refname (`gitk/v0.0.1`).  Which
> >> is still mostly fine, since not too many tools care if the internal
> >> name and the refname disagree.
> >>
> >> But, fast-export/fast-import are tools that do care: it's currently
> >> impossible to represent these tags in a fast-import stream.
> >>
> >> This patch adds an optional "name" sub-command to fast-import's "tag"
> >> top-level-command, the stream
> >>
> >>     tag foo
> >>     name bar
> >>     ...
> >>
> >> will create a tag at "refs/tags/foo" that says "tag bar" internally.
> >>
> >> These tags are things that "shouldn't" happen, so perhaps adding
> >> support for them to fast-export/fast-import is unwelcome, which is why
> >> I've marked this as an "RFC".  If this addition is welcome, then it
> >> still needs tests and documentation.
> >
> > I actually think this is a good direction to go in, and it might be
> > even an acceptable change to fsck to require only the tail match of
> > tagname and refname so that it becomes perfectly OK for Gitk's
> > "v0.0.1" tag to be stored at say "refs/tags/gitk/v0.0.1".
>
> Do you mean to change fsck to care about this it all? It doesn't care
> about the refname pointing to a tag, and AFAICT we never did.
>
> All we check is that the pseudo-"refname" is valid, i.e. if we were to
> use the thing we find on the "tag" line as a refname, does it pass
> check_refname_format()?
>
> "git tag -v" doesn't care either:
>
>         $ git update-ref refs/tags/a-v-2.31.0 3e90d4b58f3819cfd58ac61cb8668e83d3ea0563
>         $ git tag -v a-v-2.31.0
>         object a5828ae6b52137b913b978e16cd2334482eb4c1f
>         type commit
>         tag v2.31.0
>         tagger Junio C Hamano <gitster@pobox.com> 1615834385 -0700
>         [.. snip same gpgp output as for v2.31.0 itself..]
>
> I think at this point the right thing to do is to just explicitly
> document that we ignore it, and that the export/import chain should be
> as forgiving about it as possible.
>
> I.e. we have not cared about this before for validation, and
> e.g. core.alternateRefsPrefixes and such things will break any "it
> should be under refs/tags/" assumption.
>
> There's also perfectly legitimate in-the-wild use-cases for this,
> e.g. "archiving" tags to not-refs/tags/* so e.g. the upload-pack logic
> doesn't consider and follow them. Not being able to export/import those
> repositories as-is due to an overzelous data check there that's not in
> fsck.c would suck.

Not would suck, but does suck.  I had to document it as a shortcoming
of fast-export/fast-import -- see
https://www.mankier.com/1/git-filter-repo#Internals-Limitations, where
I wrote, "annotated and signed tags outside of the refs/tags/
namespace are not supported (their location will be mangled in weird
ways)".

The problem is, what's the right backward-compatible way to fix this?
Do we have to add a flag to both fast-export and fast-import to stop
assuming a "refs/tags/" prefix and use the full refname, and require
the user to pass both flags?  How is fast-import supposed to know that
"refs/alternate-tags/foo" is or isn't
"refs/tags/refs/alternate-tags/foo"?

And if we need such a flag, should fast-import die if it sees this new
"name" directive and the flag isn't given?