Re: [PATCH] ls-tree: fix --no-full-name

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 18, 2023, 16:37 UTC
Message-ID: <xmqqo7k9fa5x.fsf@gitster.g>
In-Reply-To: <d392a005-4eba-7cc7-9554-cdb8dc53975e@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 5 quoted lines

> Since 61fdbcf98b (ls-tree: migrate to parse-options, 2009-11-13) git
> ls-tree has accepted the option --no-full-name, but it does the same
> as --full-name, contrary to convention.  That's because it's defined
> using OPT_SET_INT with a value of 0, where the negative variant sets
> 0 as well.

Ouch.  Well spotted.

> Turn --no-full-name into the opposite of --full-name by using OPT_BOOL
> instead and storing the option's status directly in a variable named
> "full_name" instead of in negated form in "chomp_prefix".

Good solution, especially the flipping of the polarity of the variable is very sensible.

I wonder if there are cases where it makes sense to allow the "--no-" variant to an option parsed with OPT_SET_INT() that sets '0' as the value?

Some random findings while reading hits from "git grep OPT_SET_INT":

 * "git am --[no-]keep-cr" is implemented as a pair of explicit
   PARSE_OPT_NONEG entries in the option[] array, but wouldn't it be
   sufficient to have a single OPT_SET_INT("keep-cr")?

 * "git branch --list --no-all" is accepted, sets filter.kind to 0,
   and triggers "fatal: filter_refs: invalid type".  Shouldn't we
   detect error much earlier?

 * "git bundle create --no-quiet" is accepted and sets the progress
   variable to 0, just like "--quiet" does, which is the same issue
   as the one fixed by your patch.

 * "git clone (--no-ipv4|--no-ipv6)" are accepted and uses
   TRANSPORT_FAMILY_ALL, presumably allowing both v4 and v6.
   Shouldn't we reject these?  "fetch" and "push" share the same
   issue.

 * "git status --no-(short|long|porcelain)" are accepted and use
   STATUS_FORMAT_NONE, which probably is OK.

 * "git commit --[no-](short|long|porcelain)" are accepted and
   behave as "git status" without doing any "git commit" thing,
   which should be corrected, I think.

 * "git describe --no-exact-match" is the same as "--exact-match",
   which is the same issue as the one fixed by your patch.

 * "git remote add" has an OPT_SET_INT() entry whose short and long
   forms are (0, NULL).  What is this supposed to do?  Shouldn't
   parse-options.c:parse_options_check() notice it as an error?

 * "git reset --(soft|hard|mixed|merge|keep)" all take the negated
   form and they all become "--mixed".  It may make sense to give
   all of them PARSE_OPT_NONEG.

 * "git show-branch --no-sparse" is the same as "--sparse",
   which is the same issue as the one fixed by your patch.

 * "git show-branch --no-topo-order" is the same as "--topo-order";
   as it is the default, we probably should give PARSE_OPT_NONEG.

 * "git show-branch --no-date-order" is the same as "--topo-order",
   which does sort-of make sense.  This (and the previous one)
   relies on REV_SORT_IN_GRAPH_ORDER enum being 0, which smells a
   bit brittle.

 * "git stash push --no-all" is the same as "--no-include-untracked",
   which smells iffy but probably is OK.

Anyway, the patch looks good.  Will queue.

Thanks.

Show 59 quoted lines

> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
>  builtin/ls-tree.c          | 7 +++----
>  t/t3101-ls-tree-dirname.sh | 8 ++++++++
>  2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
> index 53073d64cb..f558db5f3b 100644
> --- a/builtin/ls-tree.c
> +++ b/builtin/ls-tree.c
> @@ -343,7 +343,7 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
>  	struct object_id oid;
>  	struct tree *tree;
>  	int i, full_tree = 0;
> -	int chomp_prefix = prefix && *prefix;
> +	int full_name = !prefix || !*prefix;
>  	read_tree_fn_t fn = NULL;
>  	enum ls_tree_cmdmode cmdmode = MODE_DEFAULT;
>  	int null_termination = 0;
> @@ -365,8 +365,7 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
>  			    MODE_NAME_STATUS),
>  		OPT_CMDMODE(0, "object-only", &cmdmode, N_("list only objects"),
>  			    MODE_OBJECT_ONLY),
> -		OPT_SET_INT(0, "full-name", &chomp_prefix,
> -			    N_("use full path names"), 0),
> +		OPT_BOOL(0, "full-name", &full_name, N_("use full path names")),
>  		OPT_BOOL(0, "full-tree", &full_tree,
>  			 N_("list entire tree; not just current directory "
>  			    "(implies --full-name)")),
> @@ -387,7 +386,7 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
>
>  	if (full_tree)
>  		prefix = NULL;
> -	options.prefix = chomp_prefix ? prefix : NULL;
> +	options.prefix = full_name ? NULL : prefix;
>
>  	/*
>  	 * We wanted to detect conflicts between --name-only and
> diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh
> index 217006d1bf..5af2dac0e4 100755
> --- a/t/t3101-ls-tree-dirname.sh
> +++ b/t/t3101-ls-tree-dirname.sh
> @@ -154,6 +154,14 @@ EOF
>  	test_output
>  '
>
> +test_expect_success 'ls-tree --no-full-name' '
> +	git -C path0 ls-tree --no-full-name $tree a >current &&
> +	cat >expected <<-EOF &&
> +	040000 tree X	a
> +	EOF
> +	test_output
> +'
> +
>  test_expect_success 'ls-tree --full-tree' '
>  	(
>  		cd path1/b/c &&
> --
> 2.41.0