On Wed, Apr 21, 2021 at 1:19 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > 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. 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?
