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: 19+ 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
2026-11-08 21:45 ` Colin Hinton
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 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.