git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Hommey <mh@glandium.org>
To: Patrick Steinhardt <ps@pks.im>
Cc: Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org, git-packagers@googlegroups.com
Subject: Re: [ANNOUNCE] Git v2.44.0
Date: Sun, 25 Feb 2024 04:55:50 +0900	[thread overview]
Message-ID: <20240224195550.ignhzidmdy3ce6q4@glandium.org> (raw)
In-Reply-To: <ZdmOZRjJ-mClBR02@framework>

On Sat, Feb 24, 2024 at 07:36:21AM +0100, Patrick Steinhardt wrote:
> Thanks for your report!
> 
> This has to be because we now initialize the refdb at a later point. The
> problem here was that before my change, we initialized the refdb at a
> point when it wasn't clear what the remote actually used as the object
> format. The consequence was twofold:
> 
>   - Cloning a repository with bundles was broken in case the remote uses
>     the SHA256 object format.
> 
>   - Cloning into a repository that uses reftables when the remote uses
>     the SHA256 object format was broken, too.
> 
> Both of these have the same root cause: because we didn't connect to the
> remote yet we had no idea what object format the remote uses. And as we
> initialized the refdb early, it was then initialized with the default
> object format, which is SHA1.
> 
> The change was to move initialization of the refdb to a later point in
> time where we know what object format the remote uses. By necessity,
> this has to be _after_ we have connected to the remote, because there is
> no way to learn about it without connecting to it.
> 
> One consequence of initializing the refdb at a later point in time is
> that we have no "HEAD" yet, and a repo without the "HEAD" file is not
> considered to be a repo. Thus, git-config(1) would now rightfully fail.
> 
> I assume that you discovered it via a remote helper that does something
> more interesting than git-config(1).

Indeed, my own usecase is a remote helper that uses libgit.a and uses
is_git_directory indirectly, but I could imagine other remote helpers that
could be using other git commands that rely on is_git_directory
returning true.

> 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`.

> But on the other hand, regressing functionality like this is of course
> bad. I was wondering whether we can get around this issue by setting
> e.g. GIT_DIR explicitly when spawning the remote helper, but I don't
> think it's as easy as that.

GIT_DIR is already set when spawning the remote helper. My remote helper
is using setup_git_directory_gently and uses the value of nongit_ok for
the cases where the executable is used without being wrapped by git (it
provides extra commands), I guess I could use whether GIT_DIR is set as
a workaround.

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

Mike

  reply	other threads:[~2024-02-24 19:56 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 [this message]
2024-02-25  7:09       ` Patrick Steinhardt
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:
  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=20240224195550.ignhzidmdy3ce6q4@glandium.org \
    --to=mh@glandium.org \
    --cc=git-packagers@googlegroups.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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).