All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tian Yuchen <cat@malon.dev>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
	Christian Couder <christian.couder@gmail.com>,
	Ayush Chandekar <ayu.chandekar@gmail.com>,
	Olamide Caleb Bello <belkid98@gmail.com>
Subject: Re: [PATCH v6] repository: move fetch_if_missing into struct repository
Date: Sun, 16 Aug 2026 14:20:50 +0800	[thread overview]
Message-ID: <59841e66-4361-484e-bc1f-131ea9b2d235@malon.dev> (raw)
In-Reply-To: <xmqqmrun8jeu.fsf@gitster.g>

On 8/15/26 23:58, Junio C Hamano wrote:
> Tian Yuchen <cat@malon.dev> writes:
> 
>> The global variable 'fetch_if_missing' controls whether a missing
>> object check should prompt a lazy fetch from a promisor remote.
>> In order to continue the libification effort, move it into
>> 'struct repository' and initialize it to 1 by default to keep the
>> previous behavior.
>>
>> builtin/fetch-pack.c, builtin/fsck.c, and builtin/rev-list.c are
>> entered via commands marked RUN_SETUP in git.c:commands[]. Their
>> 'repo' parameter is only NULL when '-h' is given outside of a
>> repository, in which case either show_usage_if_asked() or
>> parse_options()'s own '-h' handling exits the process before
>> returning. We can therefore drop their UNUSED markers and assign
>> to 'repo' directly.
>>
>> builtin/index-pack.c is entered via RUN_SETUP_GENTLY, so its
>> 'repo' pointer can be NULL any time it is run outside of a
>> repository, not only with '-h'. We keep a NULL check there and fall
>> back to 'the_repository'.
> 
> Hmph, are there legitimate situations where we run "git index-pack"
> outside a repository, or is it a user error?  Just being curious
> and not a suggestion to change the established behaviour (in other
> words, even if it turns out that it should be diagnosed as a user
> error, we shouldn't do so in the context of changing where the
> fetch_if_missing bit lives).
> 
> Other than that, this iteration looks good to me.
> 

Interesting topic. Refer to the git-index-pack documentation:

...Reads a packed archive (.pack) from the specified file, builds a pack 
index file (.idx) for it, and optionally writes a reverse-index (.rev) 
for the specified pack. The packed archive, together with the pack 
index, *can then be placed in the objects/pack/ directory of a Git 
repository*...

Does this clarify that the design intent is to operate a standalone 
.pack file, and whether or not to put it into a repository are two 
different things?

Thanks! yuchen


      reply	other threads:[~2026-08-16  6:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-15  1:18 [PATCH v1] repository: move fetch_if_missing into struct repository Tian Yuchen
2026-07-15  3:27 ` Junio C Hamano
2026-07-15  4:58   ` Tian Yuchen
2026-07-15  6:35 ` Patrick Steinhardt
2026-07-16  7:06   ` Tian Yuchen
2026-07-16 15:28   ` Junio C Hamano
2026-07-16  7:29 ` [PATCH v2] " Tian Yuchen
2026-08-01 15:53   ` Tian Yuchen
2026-08-04  8:24   ` Patrick Steinhardt
2026-08-04 17:38     ` Junio C Hamano
2026-08-05 12:34       ` Tian Yuchen
2026-08-05 12:10     ` Tian Yuchen
2026-08-07  9:41   ` [PATCH v3] " Tian Yuchen
2026-08-07 17:03     ` Junio C Hamano
2026-08-09 15:00       ` Tian Yuchen
2026-08-13  6:11     ` [PATCH v4] " Tian Yuchen
2026-08-13 16:32       ` Junio C Hamano
2026-08-14  7:24       ` [PATCH v5 0/2] " Tian Yuchen
2026-08-14  7:24         ` [PATCH v5 1/2] pack-objects: give fetch_if_missing call sites access to 'repo' Tian Yuchen
2026-08-14 14:38           ` Junio C Hamano
2026-08-15  6:31             ` Tian Yuchen
2026-08-14  7:24         ` [PATCH v5 2/2] repository: move fetch_if_missing into struct repository Tian Yuchen
2026-08-14 14:44         ` [PATCH v5 0/2] " Junio C Hamano
2026-08-15  6:47         ` [PATCH v6] " Tian Yuchen
2026-08-15 15:58           ` Junio C Hamano
2026-08-16  6:20             ` Tian Yuchen [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=59841e66-4361-484e-bc1f-131ea9b2d235@malon.dev \
    --to=cat@malon.dev \
    --cc=ayu.chandekar@gmail.com \
    --cc=belkid98@gmail.com \
    --cc=christian.couder@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 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.