git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org,  Mike Hommey <mh@glandium.org>
Subject: Re: [PATCH 2/2] builtin/clone: allow remote helpers to detect repo
Date: Mon, 04 Mar 2024 08:17:33 -0800	[thread overview]
Message-ID: <xmqqbk7urmxu.fsf@gitster.g> (raw)
In-Reply-To: <ZeVt0CAfpYFZqT2i@tanuki> (Patrick Steinhardt's message of "Mon, 4 Mar 2024 07:44:32 +0100")

Patrick Steinhardt <ps@pks.im> writes:

>> > +	 * Git commands. To do so, we:
>> > +	 *
>> > +	 *   - Create an invalid HEAD ref pointing at "refs/heads/.invalid".
>> > +	 *
>> > +	 *   - Create the "refs/" directory.
>> > +	 *
>> > +	 *   - Set up the ref storage format and repository version as
>> > +	 *     required.
>> 
>> "as required" by whom and in what way?  
>> 
>> "The code to recognize a repository requires them to be set already,
>> but they do not have to be the real value---we just assign random
>> valid values for now, let remote helper do its work and then set the
>> real values after they are done" would be a plausible interpretation
>> of the above.  Is that what is going on?
>
> Partially. While we cannot yet determine the object format, we do know
> the ref storage format as it is specified by the caller when invoking
> git-clone(1) with the `--ref-format=` switch, not by the remote repo.
> In that case, we'd have to set up the ref format accordingly and also
> set the repository version to "1".

Ah, of course.  Unlike the object format, we do not say "the other
end uses reftable, so we should do the same" and we do not have to,
thanks to some artificial limitations added to the reftable backend
not to exceed the expressiveness of the files backend.

Thanks.

  reply	other threads:[~2024-03-04 16:17 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 14:27 [PATCH 0/2] builtin/clone: allow remote helpers to detect repo Patrick Steinhardt
2024-02-27 14:27 ` [PATCH 1/2] refs/reftable: don't fail empty transactions in repo without HEAD Patrick Steinhardt
2024-02-28 11:32   ` Karthik Nayak
2024-03-04  6:44     ` Patrick Steinhardt
2024-03-04 16:28       ` Junio C Hamano
2024-03-05 11:43         ` Patrick Steinhardt
2024-03-05 15:59           ` Junio C Hamano
2024-03-06 11:17           ` [PATCH] t0610: remove unused variable assignment Patrick Steinhardt
2024-03-01  1:20   ` [PATCH 1/2] refs/reftable: don't fail empty transactions in repo without HEAD Justin Tobler
2024-03-04  6:44     ` Patrick Steinhardt
2024-02-27 14:27 ` [PATCH 2/2] builtin/clone: allow remote helpers to detect repo Patrick Steinhardt
2024-02-27 21:31   ` Junio C Hamano
2024-03-04  6:44     ` Patrick Steinhardt
2024-03-04 16:17       ` Junio C Hamano [this message]
2024-05-03  2:04   ` Mike Hommey
2024-02-27 20:58 ` [PATCH 0/2] " Junio C Hamano
2024-02-27 21:33   ` Junio C Hamano
2024-03-04  6:44     ` Patrick Steinhardt

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=xmqqbk7urmxu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=ps@pks.im \
    /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).