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

Re: git tag -h fatal error with global tag.sort config

From
Jeff King <peff@peff.net>
Date
Sep 12, 2021, 21:39 UTC
Message-ID
<YT5zrWVlplgE/PWJ@coredump.intra.peff.net>
In-Reply-To
<20210912132757.GC76263@szeder.dev>
On Sun, Sep 12, 2021 at 03:27:57PM +0200, SZEDER Gábor wrote:
Show 38 quoted lines
> Interesting.  It bisects to 47bd3d0c14 (ref-filter: don't look for
> objects when outside of a repository, 2018-11-14), which, based on the
> error message, kind of makes sense, because 'git tag' uses the general
> ref-filter sorting facility.  Now, even if 'git tag -h' is executed in
> a repository, since 99caeed05d (Let 'git <command> -h' show usage
> without a git dir, 2009-11-09) run_builtin() special-cases the '-h'
> option and does not call setup_git_directory(), so cmd_tag() and
> everything invoked from within will mistakenly think that there is no
> repository.  And cmd_tag() parses the config before parsing the
> options (of course, otherwise command line options couldn't override
> the config), so it hits this die() before parse_options would get a
> change to act on the '-h' option.
> 
> Now, 'git branch' uses the same ref-filter sorting, but the equivalent
> 'git -c branch.sort=creatordate branch -h' command does show the usage
> as expected.  The relevant difference between cmd_branch() and
> cmd_tag() is that the former special-cases the '-h' option as well
> just before it would call git_config().  Doing the same in cmd_tag()
> like in the patch below seems to fix this issue, but I'm not sure that
> this is the right fix.
> 
> 
>   ---  >8  ---
> 
> diff --git a/builtin/tag.c b/builtin/tag.c
> index 065b6bf093..31b8cc4600 100644
> --- a/builtin/tag.c
> +++ b/builtin/tag.c
> @@ -485,6 +485,9 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
>  
>  	setup_ref_filter_porcelain_msg();
>  
> +	if (argc == 2 && !strcmp(argv[1], "-h"))
> +		usage_with_options(git_tag_usage, options);
> +
>  	git_config(git_tag_config, sorting_tail);
>  
>  	memset(&opt, 0, sizeof(opt));

I think part of the problem is that git_tag_config() is pretty eager to parse the ref format. You can similarly see:

  $ git -c tag.sort=foobar tag -h
  fatal: unknown field name: foobar

If git_tag_config() just kept strings, and then we later fed them to a parser (when we knew they were needed), that would be an appropriate time to bail.

We do something similar with verify_ref_format(); it is just a string until we know we are ready to use it. But here, the format that is being used for sorting gets fed early to parse_ref_sorting(). I guess it is a bit more complicated, because it is generating a linked list. But maybe it could generate a list of to-be-parsed entries, with a function like verify_sort_format() to validate them.

-Peff
Previous: SZEDER GáborNext: Bagas Sanjaya
Message 3 of 5 in “git tag -h fatal error with global tag.sort config”
  1. Bagas SanjayaSep 12, 2021
  2. SZEDER GáborSep 12, 2021
  3. Jeff KingSep 12, 2021
  4. Bagas SanjayaSep 13, 2021
  5. Bagas SanjayaOct 18, 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.