On Tue, Apr 20 2021, Junio C Hamano wrote: > Luke Shumaker <lukeshu@xxxxxxxxxxx> 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@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.
