From: Junio C Hamano <gitster@pobox.com>
To: Colin Hinton <colinlewishinton@gmail.com>
Cc: git@vger.kernel.org, m@lfurio.us
Subject: Re: [PATCH v5] fetch.c: defer fetch.followRemoteHEAD validation
Date: Mon, 05 Oct 2026 06:07:27 -0700 [thread overview]
Message-ID: <xmqqqzi4nvn4.fsf@gitster.g> (raw)
In-Reply-To: <20261004201428.5210-1-colinlewishinton@gmail.com> (Colin Hinton's message of "Sun, 4 Oct 2026 13:14:27 -0700")
Colin Hinton <colinlewishinton@gmail.com> writes:
I see there are only two minor things remaining in this iteration.
> fetch. Leave NEEDSWORK comments at both the now unresolved call site
> in do_fetch() and at the actual defect in handle_config(), so the
> remaining scope is easy to find for a follow-up patch.
Here is one of the two. There is only one NEEDSWORK, not "at both".
Leave a NEEDSWORK comment at remote.c:handle_config() that
has a defect similar to what is fixed by this patch, so ...
should be sufficient.
Another is that
int cmd_fetch(int argc,
const char **argv,
const char *prefix,
struct repository *repo UNUSED)
{
struct fetch_config config = {
.display_format = DISPLAY_FORMAT_FULL,
.follow_remote_head_raw = NULL,
.follow_remote_head_seen = 0,
.prune = -1,
.prune_tags = -1,
.show_forced_updates = 1,
.recurse_submodules = RECURSE_SUBMODULES_DEFAULT,
.parallel = 1,
.submodule_fetch_jobs = -1,
};
will hold onto a copy of config.follow_remote_head_seen that was
read from the configuration and never frees it, so when cmd_fetch()
leaves, it technically leaks a string.
Other than these two points, this round looks very good.
Thanks.
next prev parent reply other threads:[~2026-10-05 13:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 4:00 [PATCH] fetch.c: defer fetch.followRemoteHEAD validation Colin Hinton
2026-09-22 5:32 ` Junio C Hamano
2026-09-23 5:03 ` Colin Hinton
2026-09-24 7:50 ` Matt Hunter
2026-09-25 18:48 ` Colin Hinton
2026-09-24 7:50 ` Matt Hunter
2026-09-25 19:26 ` [PATCH v2] " Colin Hinton
2026-09-25 19:40 ` Junio C Hamano
2026-09-25 20:30 ` Colin Hinton
2026-09-30 4:21 ` Matt Hunter
2026-09-30 18:46 ` Junio C Hamano
2026-10-03 4:50 ` Colin Hinton
2026-09-25 23:06 ` [PATCH v3] " Colin Hinton
2026-10-03 23:14 ` [PATCH v4] " Colin Hinton
2026-10-04 13:27 ` Junio C Hamano
2026-10-04 15:40 ` Colin Hinton
2026-10-04 17:42 ` Junio C Hamano
2026-10-04 20:14 ` [PATCH v5] " Colin Hinton
2026-10-05 9:05 ` Matt Hunter
2026-10-05 13:07 ` Junio C Hamano [this message]
2026-10-06 3:22 ` [PATCH v6] " Colin Hinton
2026-10-07 16:50 ` 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=xmqqqzi4nvn4.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=colinlewishinton@gmail.com \
--cc=git@vger.kernel.org \
--cc=m@lfurio.us \
/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.