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