archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <>
To: Mike Hommey <>
Cc: Junio C Hamano <>,,
Subject: Re: [ANNOUNCE] Git v2.44.0
Date: Sun, 25 Feb 2024 08:09:48 +0100	[thread overview]
Message-ID: <ZdrnvKRl8oGPJxOD@framework> (raw)
In-Reply-To: <>

[-- Attachment #1: Type: text/plain, Size: 2618 bytes --]

On Sun, Feb 25, 2024 at 04:55:50AM +0900, Mike Hommey wrote:
> On Sat, Feb 24, 2024 at 07:36:21AM +0100, Patrick Steinhardt wrote:
> > I have to wonder whether we ever
> > really specified what the environment of a remote helper should look
> > like when used during cloning. Conceptually it doesn't feel _wrong_ to
> > have a not-yet-initialized repo during clone.
> How about this: it should look like what you'd get from
> `git init $repo`.

The problem is that it can't. With git-init(1) you already know how the
repo should look like as you specify parameters like SHA1 vs SHA256 via
parameters. But with git-clone(1) it's a different story, as you only
learn about how the repo should look like _after_ you have connected to
the remote. And thus, after you have executed the remote helper.

This has never been a problem with the old "files" backend because it
does not encode the object format in the refdb. But the "reftable"
backend does, and thus we can only creat the refdb after we have learned
about the object format. Future refdb implementations are likely to do
similar things.

> > Another idea would be to simply pre-create HEAD regardless of the ref
> > format, pointing to an invalid ref "refs/heads/.invalid". This is the
> > same trick we use for the reftable backend, and should likely address
> > your issue.
> The interesting thing is that `git init $repo` does give you an invalid
> HEAD (and that's what would happen during git clone too), with either
> ```
> ref: refs/heads/master
> ```
> or
> ```
> ref: refs/heads/main
> ```
> depending on configuration.

HEAD in your example is not invalid, it's unborn. That's a difference
because creating the branch would succeed just fine. In the case of
"refs/heads/.invalid", creating the branch will fail because the ref
name would be refused.

With the reftable backend, we are forced to create HEAD exactly due to
the problem you have just encountered: a repo would not be discovered if
it did not exist. But its value shouldn't ever be read, because it is in
part of the reftables in "reftable/".

So as a safety mechanism, we want to make sure that the value of HEAD
cannot be interpreted like a "proper" ref. Clients that do not
understand the reftable format should not see a HEAD ref pointing to
"refs/heads/main" and then happily create or access such a branch.
That's why we want it to be an invalid ref.

That's ultimately the reason why I don't want HEAD to look like a proper
ref. But doing the "refs/heads/.invalid" workaround shouldn't be too bad,
I guess.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-02-25  7:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 17:17 [ANNOUNCE] Git v2.44.0 Junio C Hamano
2024-02-24  5:10 ` Mike Hommey
2024-02-24  6:36   ` Patrick Steinhardt
2024-02-24 19:55     ` Mike Hommey
2024-02-25  7:09       ` Patrick Steinhardt [this message]
2024-02-25 17:16         ` Junio C Hamano
2024-02-27  7:02           ` Patrick Steinhardt
2024-02-27 14:29     ` 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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZdrnvKRl8oGPJxOD@framework \ \ \ \ \ \

* 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).