From: Junio C Hamano <gitster@pobox.com>
To: "René Scharfe" <l.s.r@web.de>
Cc: Git List <git@vger.kernel.org>
Subject: Re: [PATCH] ls-tree: fix --no-full-name
Date: Tue, 18 Jul 2023 09:37:30 -0700 [thread overview]
Message-ID: <xmqqo7k9fa5x.fsf@gitster.g> (raw)
In-Reply-To: <d392a005-4eba-7cc7-9554-cdb8dc53975e@web.de> ("René Scharfe"'s message of "Tue, 18 Jul 2023 17:44:13 +0200")
René Scharfe <l.s.r@web.de> writes:
> 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.
> 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
next prev parent reply other threads:[~2023-07-18 16:37 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 15:44 [PATCH] ls-tree: fix --no-full-name René Scharfe
2023-07-18 16:37 ` Junio C Hamano [this message]
2023-07-18 20:49 ` Junio C Hamano
2023-07-21 12:41 ` René Scharfe
2023-07-21 12:41 ` René Scharfe
2023-07-21 14:37 ` Junio C Hamano
2023-07-21 19:29 ` René Scharfe
2023-07-21 20:09 ` Junio C Hamano
2023-07-21 20:14 ` Junio C Hamano
2023-07-24 12:29 ` René Scharfe
2023-07-24 18:51 ` Junio C Hamano
2023-07-24 20:09 ` René Scharfe
2023-07-24 20:50 ` Junio C Hamano
2023-07-28 6:12 ` René Scharfe
2023-07-28 9:45 ` Phillip Wood
2023-07-29 20:40 ` René Scharfe
2023-07-31 15:31 ` Junio C Hamano
2023-08-04 16:40 ` Junio C Hamano
2023-08-04 19:48 ` Phillip Wood
2023-08-05 10:40 ` René Scharfe
2023-07-24 12:29 ` [PATCH v2 0/5] show negatability of options in short help René Scharfe
2023-07-24 12:34 ` [PATCH v2 1/5] subtree: disallow --no-{help,quiet,debug,branch,message} René Scharfe
2023-07-24 12:36 ` [PATCH v2 2/5] t1502, docs: disallow --no-help René Scharfe
2023-07-24 12:38 ` [PATCH v2 3/5] t1502: move optionspec help output to a file René Scharfe
2023-07-24 12:39 ` [PATCH v2 4/5] t1502: test option negation René Scharfe
2023-07-24 12:40 ` [PATCH v2 5/5] parse-options: show negatability of options in short help René Scharfe
2023-08-05 14:33 ` [PATCH v3 0/8] " René Scharfe
2023-08-05 14:37 ` [PATCH v3 1/8] subtree: disallow --no-{help,quiet,debug,branch,message} René Scharfe
2023-08-05 14:37 ` [PATCH v3 2/8] t1502, docs: disallow --no-help René Scharfe
2023-08-05 14:38 ` [PATCH v3 3/8] t1502: move optionspec help output to a file René Scharfe
2023-08-05 14:39 ` [PATCH v3 4/8] t1502: test option negation René Scharfe
2023-08-05 14:40 ` [PATCH v3 5/8] parse-options: show negatability of options in short help René Scharfe
2023-08-05 14:43 ` [PATCH v3 6/8] parse-options: factor out usage_indent() and usage_padding() René Scharfe
2023-08-05 14:44 ` [PATCH v3 7/8] parse-options: no --[no-]no- René Scharfe
2023-08-05 14:52 ` [PATCH v3 8/8] parse-options: simplify usage_padding() René Scharfe
2023-08-05 23:04 ` Junio C Hamano
2023-07-21 12:41 ` [PATCH] show-branch: fix --no-sparse René Scharfe
2023-07-21 14:42 ` Junio C Hamano
2023-07-21 16:30 ` René Scharfe
2023-07-21 12:41 ` [PATCH] show-branch: disallow --no-{date,topo}-order René Scharfe
2023-07-21 12:41 ` [PATCH] reset: disallow --no-{mixed,soft,hard,merge,keep} René Scharfe
2023-07-21 12:41 ` [PATCH] pack-objects: fix --no-quiet René Scharfe
2023-07-21 12:41 ` [PATCH] pack-objects: fix --no-keep-true-parents René Scharfe
2023-07-21 17:03 ` Junio C Hamano
2023-07-21 12:42 ` [PATCH] branch: disallow --no-{all,remotes} René Scharfe
2023-07-21 12:42 ` [PATCH] am: unify definition of --keep-cr and --no-keep-cr René Scharfe
2023-07-21 13:41 ` [PATCH] describe: fix --no-exact-match René Scharfe
2023-07-21 14:10 ` Junio C Hamano
2023-07-21 17:00 ` Junio C Hamano
2023-08-08 21:27 ` Jeff King
2023-08-08 21:28 ` Jeff King
2023-08-09 1:43 ` Junio C Hamano
2023-08-09 14:09 ` Jeff King
2023-08-09 16:41 ` René Scharfe
2023-08-09 19:07 ` Junio C Hamano
2023-08-10 0:26 ` Jeff King
2023-08-10 1:00 ` Junio C Hamano
2023-08-10 19:45 ` René Scharfe
2023-08-10 0:41 ` Jeff King
2023-08-10 19:10 ` René Scharfe
2023-08-11 15:11 ` Jeff King
2023-08-11 17:59 ` René Scharfe
2023-08-11 18:24 ` Jeff King
2023-08-12 5:11 ` René Scharfe
2023-08-11 15:13 ` Jeff King
2023-08-11 17:59 ` René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqo7k9fa5x.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.