From: "Matt Hunter" <m@lfurio.us>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Colin Hinton" <colinlewishinton@gmail.com>, <git@vger.kernel.org>
Subject: Re: [PATCH v2] remote.c: defer remote.<name>.followRemoteHEAD validation
Date: Fri, 06 Nov 2026 04:34:46 -0500 [thread overview]
Message-ID: <DMO0XC1PL4MP.1J5830XZ4GCS5@lfurio.us> (raw)
In-Reply-To: <xmqqjymqobc3.fsf@gitster.g>
On Thu Nov 5, 2026 at 11:03 PM EST, Junio C Hamano wrote:
>
> Hmph, interesting. Can you rewrite Colin's patch using this, and
> then merge the result into 'seen' (after reverting Colin's topic
> ch/remote-defer-follow-remote-head-validation from 'seen' first) to
> see how badly it crashes with other topics in flight?
I still have the commit sitting around. I tried this and a replay of
the current topic to compare -- the conflict is the same in both
cases. eg: Nothing else in flight is touching the
get_follow_remote_head() function.
static int do_fetch(struct transport *transport,
struct refspec *rs,
const struct fetch_config *config,
struct list_objects_filter_options *filter_options,
struct oidset *updated_tips)
{
struct ref_transaction *transaction = NULL;
struct ref *ref_map = NULL;
struct display_state display_state = { 0 };
int autotags = (transport->remote->fetch_tags == 1);
int retcode = 0;
const struct ref *remote_refs;
struct transport_ls_refs_options transport_ls_refs_options =
TRANSPORT_LS_REFS_OPTIONS_INIT;
struct fetch_head fetch_head = { 0 };
struct strbuf err = STRBUF_INIT;
struct ref_update_display_info_array display_array = { 0 };
struct strmap rejected_refs = STRMAP_INIT;
int summary_width = 0;
int follow_remote_head = FOLLOW_REMOTE_NEVER;
<<<<<<< HEAD
bool apply_follow_remote_head_config = false;
=======
const char *no_warn_branch = NULL;
>>>>>>> try-merge
if (tags == TAGS_DEFAULT) {
if (transport->remote->fetch_tags == 2)
tags = TAGS_SET;
if (transport->remote->fetch_tags == -1)
tags = TAGS_UNSET;
}
/* if not appending, truncate FETCH_HEAD */
if (!append && write_fetch_head) {
retcode = truncate_fetch_head();
if (retcode)
goto cleanup;
}
if (rs->nr) {
refspec_ref_prefixes(rs, &transport_ls_refs_options.ref_prefixes);
} else if (transport->remote->fetch.nr) {
refspec_ref_prefixes(&transport->remote->fetch,
&transport_ls_refs_options.ref_prefixes);
apply_follow_remote_head_config = true;
<<<<<<< HEAD
/*
* The configured refspec may not cover the current
* branch's upstream (e.g. a narrowed -t refspec), so
* make sure we can still fetch it regardless.
*/
collect_upstream_from_remote(the_repository, transport->remote,
NULL, &transport_ls_refs_options.ref_prefixes);
} else {
/*
* The --refmap command line option, if given, takes
* precedence over remote.<name>.fetchRefmap.
*/
struct refspec *effective_refmap = refmap.nr ? &refmap :
&transport->remote->refmap;
if (effective_refmap->nr) {
branches_tracking_remote(the_repository, transport->remote,
&transport_ls_refs_options.ref_prefixes);
apply_follow_remote_head_config = true;
} else {
collect_upstream_from_remote(the_repository, transport->remote,
NULL, &transport_ls_refs_options.ref_prefixes);
=======
if (transport->remote->fetch.nr) {
refspec_ref_prefixes(&transport->remote->fetch,
&transport_ls_refs_options.ref_prefixes);
follow_remote_head =
get_follow_remote_head(transport, config,
&no_warn_branch);
}
if (branch && branch_has_merge_config(branch) &&
!strcmp(branch->remote_name, transport->remote->name)) {
int i;
for (i = 0; i < branch->merge_nr; i++) {
strvec_push(&transport_ls_refs_options.ref_prefixes,
branch->merge[i]->src);
}
>>>>>>> try-merge
}
/*
* If there are no refs specified to fetch, then we just
* fetch HEAD; mention that to narrow the advertisement.
*/
if (!transport_ls_refs_options.ref_prefixes.nr)
strvec_push(&transport_ls_refs_options.ref_prefixes,
"HEAD");
}
next prev parent reply other threads:[~2026-11-06 9:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 23:55 [PATCH v1] remote.c: defer remote.<name>.followRemoteHEAD validation Colin Hinton
2026-10-19 15:37 ` Junio C Hamano
2026-10-19 21:24 ` Matt Hunter
2026-10-21 16:30 ` Colin Hinton
2026-10-22 12:39 ` Matt Hunter
2026-10-23 18:50 ` [PATCH v2] " Colin Hinton
2026-10-23 21:59 ` Junio C Hamano
2026-10-24 9:28 ` Matt Hunter
2026-10-24 16:47 ` Junio C Hamano
2026-10-25 2:16 ` Junio C Hamano
2026-10-28 2:56 ` Colin Hinton
2026-10-28 14:26 ` Junio C Hamano
2026-10-30 7:04 ` Matt Hunter
2026-10-30 15:12 ` Junio C Hamano
2026-11-01 0:00 ` Matt Hunter
2026-11-06 4:03 ` Junio C Hamano
2026-11-06 9:34 ` Matt Hunter [this message]
2026-11-06 16:15 ` 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=DMO0XC1PL4MP.1J5830XZ4GCS5@lfurio.us \
--to=m@lfurio.us \
--cc=colinlewishinton@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox