git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Taylor Blau <me@ttaylorr.com>,
	 git@vger.kernel.org,  Igor Todorovski <itodorov@ca.ibm.com>,
	 Bence Ferdinandy <bence@ferdinandy.com>
Subject: Re: [PATCH 8/9] fetch: avoid ls-refs only to ask for HEAD symref update
Date: Mon, 17 Mar 2025 12:01:21 -0700	[thread overview]
Message-ID: <xmqq1puva3cu.fsf@gitster.g> (raw)
In-Reply-To: <20250317180604.GB704553@coredump.intra.peff.net> (Jeff King's message of "Mon, 17 Mar 2025 14:06:04 -0400")

Jeff King <peff@peff.net> writes:

> That was my intuition, too, but there's a case in between. Doing:
>
>   git fetch origin main
>
> will update HEAD, too (with the current code).

Good point, and I do not think it should.

> But if and only if it
> points to "main"! Is that something we want to keep? It feels like it
> could sometimes be useful, but it is awfully hard to explain.

Again, I do not think it should update HEAD.  Is this something hard
to fix?  When I say "please tell me where their main branch is",
that is what I mean.  I didn't ask about their HEAD, period.  Unlike
"git fetch" (that default to 'origin') and "git fetch origin", which
is "please update our view of 'origin'" and should update HEAD if it
is missing (or configured to be updated every time).

> So I could see going in two different directions:
>
>   1. Only do the HEAD update when we are using the configured refspecs.
>
>   2. Do the HEAD update even when we are not fetching its destination,
>      but do not otherwise trigger ls-refs to discover it (so basically,
>      not on object-only fetches). This kicks in for more cases, but is
>      hard to explain.
>
> Both are a user-visible divergence from how the feature behaves now (and
> so I did not want to touch that in my series), but if we are all in
> agreement, we can fix it on top. I do think option 1 (i.e., what you are
> suggesting in your email) is how I would have done it if starting from
> scratch. And the current rules are weird enough and the feature is new
> enough that I think it is OK to change.

Yup, I do think #1 is the way to go.

Thanks.

  reply	other threads:[~2025-03-17 19:01 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-30  3:49 Tags are no longer fetched when fetching specific commit Igor Todorovski
2025-02-13 22:38 ` Taylor Blau
2025-02-14 13:53   ` Bence Ferdinandy
2025-02-14 18:35   ` Junio C Hamano
2025-02-21  7:25     ` Jeff King
2025-03-07 23:27 ` [PATCH] fetch: fix following tags when fetching specific OID Taylor Blau
2025-03-07 23:32   ` Taylor Blau
2025-03-08  0:10   ` Junio C Hamano
2025-03-08  3:23   ` Bence Ferdinandy
2025-03-09  3:01   ` [PATCH 0/9] fetch: further ref-prefix cleanups and optimizations Jeff King
2025-03-09  3:01     ` [PATCH 1/9] t5702: fix typo in test name Jeff King
2025-03-12 21:30       ` Taylor Blau
2025-03-13  5:37         ` Jeff King
2025-03-09  3:01     ` [PATCH 2/9] t5516: prefer "oid" to "sha1" in some test titles Jeff King
2025-03-09  3:02     ` [PATCH 3/9] t5516: drop NEEDSWORK about v2 reachability behavior Jeff King
2025-03-12 21:30       ` Taylor Blau
2025-03-09  3:02     ` [PATCH 4/9] t5516: beef up exact-oid ref prefixes test Jeff King
2025-03-09  3:07     ` [PATCH 5/9] refspec_ref_prefixes(): clean up refspec_item logic Jeff King
2025-03-12 21:38       ` Taylor Blau
2025-03-13  5:41         ` Jeff King
2025-03-13 13:26           ` Junio C Hamano
2025-03-17 22:24             ` [PATCH 0/4] refspec: treat 'fetch' as a Boolean value Taylor Blau
2025-03-17 22:24               ` [PATCH 1/4] " Taylor Blau
2025-03-18  0:24                 ` Jeff King
2025-03-18  0:26                   ` Jeff King
2025-03-18 22:44                   ` Taylor Blau
2025-03-17 22:24               ` [PATCH 2/4] refspec: replace `refspec_init()` with fetch/push variants Taylor Blau
2025-03-17 22:24               ` [PATCH 3/4] refspec: remove refspec_item_init_or_die() Taylor Blau
2025-03-17 22:24               ` [PATCH 4/4] refspec: replace `refspec_item_init()` with fetch/push variants Taylor Blau
2025-03-17 23:26               ` [PATCH 0/4] refspec: treat 'fetch' as a Boolean value Junio C Hamano
2025-03-18 22:40                 ` Taylor Blau
2025-03-18 22:50             ` [PATCH v2 " Taylor Blau
2025-03-18 22:50               ` [PATCH v2 1/4] " Taylor Blau
2025-03-18 22:50               ` [PATCH v2 2/4] refspec: replace `refspec_init()` with fetch/push variants Taylor Blau
2025-03-18 22:50               ` [PATCH v2 3/4] refspec: remove refspec_item_init_or_die() Taylor Blau
2025-03-18 22:50               ` [PATCH v2 4/4] refspec: replace `refspec_item_init()` with fetch/push variants Taylor Blau
2025-03-19 15:31               ` [PATCH v2 0/4] refspec: treat 'fetch' as a Boolean value Elijah Newren
2025-03-17 22:00           ` [PATCH 5/9] refspec_ref_prefixes(): clean up refspec_item logic Taylor Blau
2025-03-17 23:25             ` Junio C Hamano
2025-03-18 22:47               ` Taylor Blau
2025-03-09  3:08     ` [PATCH 6/9] fetch: ask server to advertise HEAD for config-less fetch Jeff King
2025-03-12 21:43       ` Taylor Blau
2025-03-13  5:46         ` Jeff King
2025-03-13 12:26           ` Junio C Hamano
2025-03-17 22:23             ` Taylor Blau
2025-03-09  3:10     ` [PATCH 7/9] fetch: stop protecting additions to ref-prefix list Jeff King
2025-03-12 21:45       ` Taylor Blau
2025-03-09  3:20     ` [PATCH 8/9] fetch: avoid ls-refs only to ask for HEAD symref update Jeff King
2025-03-13 15:53       ` Junio C Hamano
2025-03-17 18:06         ` Jeff King
2025-03-17 19:01           ` Junio C Hamano [this message]
2025-03-18  5:39             ` [PATCH 0/2] limiting followRemoteHEAD being used Jeff King
2025-03-18  5:40               ` [PATCH 1/2] fetch: only respect followRemoteHEAD with configured refspecs Jeff King
2025-03-18 23:02                 ` Taylor Blau
2025-03-18  5:41               ` [PATCH 2/2] fetch: don't ask for remote HEAD if followRemoteHEAD is "never" Jeff King
2025-03-18 19:18               ` [PATCH 0/2] limiting followRemoteHEAD being used Junio C Hamano
2025-03-18 23:02                 ` Taylor Blau
2025-03-09  3:21     ` [PATCH 9/9] fetch: use ref prefix list to skip ls-refs Jeff King
2025-03-12 21:29     ` [PATCH 0/9] fetch: further ref-prefix cleanups and optimizations Taylor Blau
2025-03-12 21:49       ` Taylor Blau
2025-03-13  5:50         ` Jeff King

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=xmqq1puva3cu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=bence@ferdinandy.com \
    --cc=git@vger.kernel.org \
    --cc=itodorov@ca.ibm.com \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    /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;
as well as URLs for NNTP newsgroup(s).