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

[Luke Shumaker <lukeshu@lukeshu.com>]

On Wed, 21 Apr 2021 02:18:58 -0600,
Ævar Arnfjörð Bjarmason wrote:
> > Luke Shumaker <lukeshu@lukeshu.com> writes:
> >> 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.

...

> All we [fsck] 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.

With that in mind, should I flip it around, to have the refname be
more flexible?  Have the stream

   tag foo
   refname refs/tags/bar
   ...

create a tag at "refs/tags/bar" that says "tag foo" internally?

-- 
Happy hacking,
~ Luke Shumaker