From: Patrick Steinhardt <ps@pks.im>
To: Mike Hommey <mh@glandium.org>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, git-packagers@googlegroups.com
Subject: Re: [ANNOUNCE] Git v2.44.0
Date: Tue, 27 Feb 2024 15:29:47 +0100 [thread overview]
Message-ID: <Zd3x23jVejP7VL0c@tanuki> (raw)
In-Reply-To: <ZdmOZRjJ-mClBR02@framework>
[-- Attachment #1: Type: text/plain, Size: 3449 bytes --]
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@pks.im/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2024-02-27 14:41 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
2024-02-25 17:16 ` Junio C Hamano
2024-02-27 7:02 ` Patrick Steinhardt
2024-02-27 14:29 ` Patrick Steinhardt [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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zd3x23jVejP7VL0c@tanuki \
--to=ps@pks.im \
--cc=git-packagers@googlegroups.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mh@glandium.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).