All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Igor Todorovski <itodorov@ca.ibm.com>,
	Bence Ferdinandy <bence@ferdinandy.com>
Subject: Re: [PATCH 5/9] refspec_ref_prefixes(): clean up refspec_item logic
Date: Wed, 12 Mar 2025 17:38:05 -0400	[thread overview]
Message-ID: <Z9H+vWHFkATWNLxt@nand.local> (raw)
In-Reply-To: <20250309030706.GE2334191@coredump.intra.peff.net>

On Sat, Mar 08, 2025 at 10:07:06PM -0500, Jeff King wrote:
> The point of refspec_ref_prefixes() is to look over the set of refspecs
> and set up an appropriate list of "ref-prefix" strings to send to the
> server.

While we're cleaning things up, I wonder if it is worth (slightly)
renaming this function to something more descriptive, like:

    refspecs_to_ref_prefixes()

, where we pluralize "refspec" and add "to" to make it clear that we're
converting from one to the other.

> Of course this is all completely academic. We have still not implemented
> a v2 push protocol, so even though we do call this function for pushes,
> we'd never actually send these ref-prefix lines.
>
> However, given the effort I spent to figure out what was going on here,
> and the overlapping exact_sha1 checks, I'd like to rewrite this to
> preemptively fix the bug, and hopefully make it less confusing.

All makes sense.

> This splits the "if" at the top-level into fetch vs push, and then each
> handles exact_sha1 appropriately itself. The check for negative refspecs
> remains outside of either (there is no protocol support for them, so we
> never send them to the server, but rather use them only to reduce the
> advertisement we receive).
>
> The resulting behavior should be identical for fetches, but hopefully
> sets us up better for a potential future v2 push.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This could be dropped without affecting the rest of the series if it's
> too churn-y.
>
>  refspec.c | 22 ++++++++++++++++------
>  1 file changed, 16 insertions(+), 6 deletions(-)
>
> diff --git a/refspec.c b/refspec.c
> index 4cb80b5208..c6ad515f04 100644
> --- a/refspec.c
> +++ b/refspec.c
> @@ -246,14 +246,24 @@ void refspec_ref_prefixes(const struct refspec *rs,
>  		const struct refspec_item *item = &rs->items[i];
>  		const char *prefix = NULL;
>
> -		if (item->exact_sha1 || item->negative)
> +		if (item->negative)
>  			continue;
> -		if (rs->fetch == REFSPEC_FETCH)
> -			prefix = item->src;
> -		else if (item->dst)
> -			prefix = item->dst;
> -		else if (item->src && !item->exact_sha1)
> +
> +		if (rs->fetch == REFSPEC_FETCH) {

Do you think it'd be worth handling rs->fetch in a switch/case block? At
least that would allow us to catch unknown values more easily, though it
seems unlikely we'd ever add any :-).

> +			if (item->exact_sha1)
> +				continue;
>  			prefix = item->src;
> +		} else {
> +			/*
> +			 * Pushes can have an explicit destination like
> +			 * "foo:bar", or can implicitly use the src for both
> +			 * ("foo" is the same as "foo:foo").
> +			 */
> +			if (item->dst)
> +				prefix = item->dst;
> +			else if (item->src && !item->exact_sha1)
> +				prefix = item->src;
> +		}

All makes sense.

Thanks,
Taylor

  reply	other threads:[~2025-03-12 21:38 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 [this message]
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
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=Z9H+vWHFkATWNLxt@nand.local \
    --to=me@ttaylorr.com \
    --cc=bence@ferdinandy.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=itodorov@ca.ibm.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 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.