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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).