All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 3/3] refspec: stop depending on `the_repository`
Date: Fri, 17 Jul 2026 08:02:13 +0200	[thread overview]
Message-ID: <alnFZe5jqvFdHQdh@pks.im> (raw)
In-Reply-To: <xmqqpl0mejlc.fsf@gitster.g>

On Thu, Jul 16, 2026 at 01:59:59PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > The only remaining user of `the_hash_algo` in "refspec.c" is
> > `refspec_append()`, which needs to know the hash algorithm so that it
> > can parse the appended refspec item. In contrast to the functions
> > adapted in the preceding commit, this function always operates on a
> > `struct refspec`. As that structure is expected to only ever contain
> > refspecs that all use the same hash function it doesn't make sense
> > though to adapt each caller.
> >
> > Instead, adapt the structure itself so that it gets initialized with a
> > hash function and use that hash function to parse new refspec items.
> > Adapt callers accordingly.
> >
> > This removes the final dependency on the global repository variable in
> > "refspec.c", so we can drop `USE_THE_REPOSITORY_VARIABLE`.
> 
> While we lost some references to the_repository, we gained
> more references to the_hash_algo in exchange.  Because
> the_hash_algo is defined in terms of the_repository->hash_algo,
> it is only available when the_repository is still in use.
> So these changes do not really help callers, and only leave
> more for them to clean up later.
> 
> Which is probably fine.  We have to start somewhere, and
> refspec parsing is a fairly well-isolated corner of the
> universe that serves as a good starting point.

Yup, this patch series follows our typical approach of making one
subsystem `the_repository`-clean, but bumping that dependency up into
the next-higher level.

I've got a bunch of follow-up patch series that'll also convert some of
those higher-up dependencies. Most importantly, I'm converting all
subsystems that relate to the transport layer, as I'm on a very naive
quest to try and get git-clone(1) working without `the_repository`.
Let's see how far I get.

Patrick

      reply	other threads:[~2026-07-17  6:02 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-16 12:38 [PATCH 0/3] refspec: remove dependency on `the_repository` Patrick Steinhardt
2026-07-16 12:38 ` [PATCH 1/3] refspec: group related structures and functions Patrick Steinhardt
2026-07-16 12:38 ` [PATCH 2/3] refspec: let callers pass in hash algorithm when parsing items Patrick Steinhardt
2026-07-16 12:38 ` [PATCH 3/3] refspec: stop depending on `the_repository` Patrick Steinhardt
2026-07-16 20:59   ` Junio C Hamano
2026-07-17  6:02     ` Patrick Steinhardt [this message]

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=alnFZe5jqvFdHQdh@pks.im \
    --to=ps@pks.im \
    --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.