From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Jeff King <peff@peff.net>,
git@vger.kernel.org, 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: Mon, 17 Mar 2025 16:25:07 -0700 [thread overview]
Message-ID: <xmqqplif5jfw.fsf@gitster.g> (raw)
In-Reply-To: <Z9ibhJxjlc2DxKdX@nand.local> (Taylor Blau's message of "Mon, 17 Mar 2025 18:00:36 -0400")
Taylor Blau <me@ttaylorr.com> writes:
> OK... I agree that these are at least named confusingly ;-). We could do
> something like:
"Type" is so overly generic a word that it is only marginally better
than .fetch that is not a Boolean. And in a sense it is worse. At
least .fetch hints us that it wants to choose between fetch and
something else, most likely push, but .type does not tell us what
kind of type it is about.
Do we anticipate that we would acquire a new "type" other than FETCH
and PUSH? If not, .fetch = yes/no might be a better choice and if
the meaning of the member is so obvious, we may even be able to lose
REFSPEC_{FETCH,PUSH} symbols for its value.
On the other hand, if we were to add new kind of refspec used when
doing something other than fetch and push (perhaps when bundling? I
dunno), then the member specifies how the transfer goes, perhaps, so
.transfer = REFSPEC_{FETCH,PUSH,BUNDLE} might be a better choice.
But the refspecs are per remote thing (whether the remote is
configured or the refspec is used as a one-shot basis fetching from
or pushing to a remote) and while you can fetch from a bundle, you
cannot push to it, and even if the system is updated to allow
pushing into a bundle (which I do not think is such a bad idea), the
refspec used in such a case would still be either fetch refspec or
push refspec, so perhaps a new, third kind of refspec would not fit
well within the design after all.
So, if we can reasonably expect that the choice will stay between
fetch and push and we wouldn't be adding a new kind, I think
reverting the meaning of .fetch to yes/no and getting rid of
REFSPEC_{FETCH,PUSH} may be a better approach. If we stil want to
keep the descriptive CPP macro, then perhaps .transfer (or
.direction) that lets us choose between fetch or push? I dunno.
> , which gives us the "default" case in the switch statement. But this
> really is a boolean. I wonder if we should just use 0/1 constants and
> leave the field name alone. That would turn something like:
>
> if (rs->fetch == REFSPEC_FETCH) { ... }
>
> into:
>
> if (rs->fetch) { ... }
>
> , which I think is cleaner. There's no reason to rename true/false to
> FETCH and PUSH if the field name itself is already 'fetch'.
Yup, that makes two of us.
next prev parent reply other threads:[~2025-03-17 23:25 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 [this message]
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=xmqqplif5jfw.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).