From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Derrick Stolee <stolee@gmail.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jan 2025, #06; Wed, 22)
Date: Wed, 22 Jan 2025 17:52:30 -0800 [thread overview]
Message-ID: <xmqq5xm6uwip.fsf@gitster.g> (raw)
In-Reply-To: <20250123003613.GA3900660@coredump.intra.peff.net> (Jeff King's message of "Wed, 22 Jan 2025 19:36:13 -0500")
Jeff King <peff@peff.net> writes:
> Since this hit 'next', it made it into my Coverity runs, producing the
> small fixup below.
Thanks. A greedy me wonders if things like this can be caught by
them a bit earlier before they hit 'next', though ;-)
> -- >8 --
> Subject: [PATCH] path-walk: drop redundant parse_tree() call
>
> This call to parse_tree() was flagged by Coverity for ignoring the
> return value. But if we look a little further up the function, we can
> see that there is already a call to parse_tree_gently(), and we'll
> return early if that fails. So by this point the tree will always be
> parsed, and the call is redundant.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> path-walk.c | 1 -
> 1 file changed, 1 deletion(-)
Nice way to use extended context to show why the change makes sense.
Will queue. Thanks.
> diff --git a/path-walk.c b/path-walk.c
> index 136ec08fb0..9715a5550e 100644
> --- a/path-walk.c
> +++ b/path-walk.c
> @@ -116,27 +116,26 @@ static int add_tree_entries(struct path_walk_context *ctx,
>
> if (!tree) {
> error(_("failed to walk children of tree %s: not found"),
> oid_to_hex(oid));
> return -1;
> } else if (parse_tree_gently(tree, 1)) {
> error("bad tree object %s", oid_to_hex(oid));
> return -1;
> }
>
> strbuf_addstr(&path, base_path);
> base_len = path.len;
>
> - parse_tree(tree);
> init_tree_desc(&desc, &tree->object.oid, tree->buffer, tree->size);
> while (tree_entry(&desc, &entry)) {
> struct type_and_oid_list *list;
> struct object *o;
> /* Not actually true, but we will ignore submodules later. */
> enum object_type type = S_ISDIR(entry.mode) ? OBJ_TREE : OBJ_BLOB;
>
> /* Skip submodules. */
> if (S_ISGITLINK(entry.mode))
> continue;
>
> /* If the caller doesn't want blobs, then don't bother. */
> if (!ctx->info->blobs && type == OBJ_BLOB)
next prev parent reply other threads:[~2025-01-23 1:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-22 22:48 What's cooking in git.git (Jan 2025, #06; Wed, 22) Junio C Hamano
2025-01-23 0:36 ` Jeff King
2025-01-23 1:52 ` Junio C Hamano [this message]
2025-01-31 23:34 ` Jeff King
2025-01-31 23:39 ` Jeff King
2025-01-31 23:49 ` Junio C Hamano
2025-02-01 2:29 ` Jeff King
2025-02-02 23:39 ` Junio C Hamano
2025-02-03 13:51 ` Junio C Hamano
2025-02-04 2:35 ` Jeff King
2025-02-02 18:09 ` D. Ben Knoble
2025-02-02 23:33 ` Junio C Hamano
2025-02-03 15:33 ` Jeff King
2025-01-23 0:38 ` Eric Sunshine
2025-01-23 1:53 ` Junio C Hamano
2025-01-23 17:36 ` Taylor Blau
2025-01-24 6:07 ` Patrick Steinhardt
2025-01-24 12:55 ` Toon Claes
2025-01-24 17:05 ` Junio C Hamano
2025-01-24 16:02 ` Junio C Hamano
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=xmqq5xm6uwip.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=stolee@gmail.com \
/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.