On Sat, Feb 24, 2024 at 07:36:21AM +0100, Patrick Steinhardt wrote: > On Sat, Feb 24, 2024 at 02:10:40PM +0900, Mike Hommey wrote: > > Hi, > > > > On Fri, Feb 23, 2024 at 09:17:07AM -0800, Junio C Hamano wrote: > > > Patrick Steinhardt (139): > > > builtin/clone: create the refdb with the correct object format > > > > I haven't analyzed how/why exactly yet, but I've bisected a regression > > in the behavior of is_git_directory() during a clone to originate from > > this change. > > > > Here's a way to reproduce the problem: > > > > ``` > > $ cat > git-remote-foo <<EOF > > #!/bin/sh > > git config --local -l >&2 > > exit 1 > > EOF > > $ chmod +x git-remote-foo > > $ PATH=$PWD:$PATH git clone foo::bar > > ``` > > > > With versions < 2.44.0, it displays the local configuration, e.g.: > > ``` > > core.repositoryformatversion=0 > > core.filemode=true > > core.bare=false > > core.logallrefupdates=true > > remote.origin.url=foo::bar > > ``` > > > > but with 2.44.0, it fails with: > > ``` > > fatal: --local can only be used inside a git repository > > ``` > > 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). 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. > > 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. > > 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. > > I will have a deeper look on Tuesday and send a patch. I've sent that patch in a separate thread at [1]. Patrick [1]: https://lore.kernel.org/git/cover.1709041721.git.ps@xxxxxx/
Attachment:
signature.asc
Description: PGP signature
