Git development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox