git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Elijah Newren <newren@gmail.com>
Date
Apr 21, 2021, 18:41 UTC
Message-ID
<CABPp-BF-rHnxvz0sAFAujXkiNwSjtpRQA4uvxT=a3z8v_sYbAA@mail.gmail.com>
In-Reply-To
<xmqqa6ps4otm.fsf@gitster.g>
On Tue, Apr 20, 2021 at 2:40 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 82 quoted lines
>
> 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".
>
> > diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> > index 39cfa05b28..6514b42d28 100644
> > --- a/Documentation/git-fast-import.txt
> > +++ b/Documentation/git-fast-import.txt
> > @@ -824,6 +824,7 @@ lightweight (non-annotated) tags see the `reset` command below.
> >  ....
> >       'tag' SP <name> LF
> >       mark?
> > +     ('name' SP <name> LF)?
> >       'from' SP <commit-ish> LF
> >       original-oid?
> >       'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
>
> The documentation after this part must be updated, too.  Here is my
> attempt.
>
>  Documentation/git-fast-import.txt | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git c/Documentation/git-fast-import.txt w/Documentation/git-fast-import.txt
> index 39cfa05b28..c3c5a7ed16 100644
> --- c/Documentation/git-fast-import.txt
> +++ w/Documentation/git-fast-import.txt
> @@ -822,22 +822,28 @@ Creates an annotated tag referring to a specific commit.  To create
>  lightweight (non-annotated) tags see the `reset` command below.
>
>  ....
> -       'tag' SP <name> LF
> +       'tag' SP <refname> LF
>         mark?
> +       ('name' SP <tagname> LF)?
>         'from' SP <commit-ish> LF
>         original-oid?
>         'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
>         data
>  ....
>
> -where `<name>` is the name of the tag to create.
> +where `<refname>` is also used as `<tagname>` if `name` option is
> +not given.
>
> -Tag names are automatically prefixed with `refs/tags/` when stored
> +The `<tagname>` is used as the name of the tag that is stored in the
> +tag object, while the `<refname>` determines where in the ref hierarchy
> +the tag reference that points at the resulting tag object goes.
> +
> +The `<refname>` is prefixed with `refs/tags/` when stored
>  in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would
> -use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the
> +use just `RELENG-1_0-FINAL` for `<refname>`, and fast-import will write the
>  corresponding ref as `refs/tags/RELENG-1_0-FINAL`.

Going on a slight tangent since you didn't introduce this, but since you're modifying this exact documentation...

I hate the assumed "refs/tags/" prefix. Especially since the "commit" and "reset" directives require full renames, why should tags be so special? The special casing reminds me of the ref-updated hook in gerrit (where branches would sometimes come without the "refs/heads/" prefix) and all the problems it caused for years until they finally fixed it to always specify full refnames. In this particular case, the "refs/tags/" assumption breaks exporting/importing of some real-world repos by mangling tag locations in weird ways -- though I never bothered to fix it because those tags appeared to already be broken given the fact that the name inside the tag didn't match the name of the actual ref. (To be honest, though, I was never sure why the name of the tag was recorded inside the tag itself.)

Previous: Ævar Arnfjörð BjarmasonNext: Junio C Hamano
Message 10 of 20 in “fast-export, fast-import: Let tags specify an internal name”
  1. fast-export, fast-import: Let tags specify an internal nameLuke Shumaker, Apr 20, 2021
  2. Junio C HamanoApr 20, 2021
  3. Ævar Arnfjörð BjarmasonApr 21, 2021
  4. Luke ShumakerApr 21, 2021
  5. Junio C HamanoApr 21, 2021
  6. Elijah NewrenApr 21, 2021
  7. Luke ShumakerApr 21, 2021
  8. Elijah NewrenApr 21, 2021
  9. Ævar Arnfjörð BjarmasonApr 22, 2021
  10. Elijah NewrenApr 21, 2021
  11. Junio C HamanoApr 21, 2021
  12. Elijah NewrenApr 21, 2021
  13. Ævar Arnfjörð BjarmasonApr 22, 2021
  14. Elijah NewrenApr 22, 2021
  15. Ævar Arnfjörð BjarmasonApr 21, 2021
  16. Luke ShumakerApr 21, 2021
  17. Luke ShumakerApr 21, 2021
  18. Elijah NewrenApr 21, 2021
  19. Junio C HamanoApr 21, 2021
  20. Luke ShumakerApr 23, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.