Git development
 help / color / mirror / Atom feed
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");
	}

  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