From: Jeff King <peff@peff.net>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Adam Majer <adamm@zombino.com>,
git@vger.kernel.org
Subject: Re: git clone of empty repositories doesn't preserve hash
Date: Thu, 27 Apr 2023 00:56:43 -0400 [thread overview]
Message-ID: <20230427045643.GB982277@coredump.intra.peff.net> (raw)
In-Reply-To: <ZEmMUFR7AJn+v7jV@tapette.crustytoothpaste.net>
On Wed, Apr 26, 2023 at 08:40:48PM +0000, brian m. carlson wrote:
> On 2023-04-26 at 10:51:34, Jeff King wrote:
> > We could send a capabilities^{} line, which Git has supported on the
> > client side since eb398797cd (connect: advertized capability is not a
> > ref, 2016-09-09). So sending it should not break even old clients
> > (though we would have to check what alternate implementations like
> > libgit2 or dulwich do; we know JGit supports it).
>
> I have a patch which does exactly this, which I will be sending shortly.
> I've confirmed that libgit2 and JGit support it, which is unsurprising,
> since all of the implementations, Git included, share the same code. In
> addition, this is the behaviour we document as supporting, so all
> implementations should support it.
Yeah, I was worried about how accurate that "should" is. :)
Since you checked the others, I peeked at dulwich's code, and it appears
to support it, too (I didn't actually run a test, but the code is pretty
clear). It doesn't support sha256 at all, but that's OK. What I'd be
concerned about is breaking clients when there is no useful capability
to advertise (though of course we could decide to send capabilities^{}
only when there is something useful to say).
> > However, the object-format support here was broken until the very recent
> > 13e67aa39b (v0 protocol: fix sha1/sha256 confusion for capabilities^{},
> > 2023-04-14), so it would only be useful going forward (before then we'd
> > die(), but maybe that is preferable to having the wrong object format?).
>
> I think it's better to die than to silently have the wrong object
> format, and it also prevents the problem if other clients using v0 or v1
> (which effectively have to be supported for compatibility, while v2 is
> optional) try to clone from a fixed server.
OK, good. So we can ignore that recently fixed bug (which only affects
the case where older versions are cloning something whose hash format
does not match theirs).
> > I'm not sure it's worth the effort, though. If you want to use sha256
> > everywhere and tell the other side about it, you need a modern client
> > anyway, and that means the ability to speak v2. So this would only
> > matter if for some reason the v2 probe was being ignored (e.g., proxies
> > eating it, ssh refusing environment variable, etc), which itself are
> > things that ideally would be fixed (and can maybe one day even go away
> > if we optimistically default to v2).
>
> Using v2 everywhere is difficult because many SSH servers still don't
> pass GIT_PROTOCOL by default, meaning that we're stuck with v0 and v1.
> In retrospect, sending an environment variable here was not a great
> decision, but we're stuck with it now.
True (I even got bit by this at one point, not realizing that I wasn't
using v2 with one of my personal servers). I certainly don't have an
objection if you're willing to do the work.
It would also allow us to fix the long-broken "unborn HEAD" problem for
v0 in an empty repo (though I am also fine if we don't go that far).
-Peff
next prev parent reply other threads:[~2023-04-27 4:56 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-05 10:28 git clone of empty repositories doesn't preserve hash Adam Majer
2023-04-05 19:04 ` Junio C Hamano
2023-04-05 19:47 ` Adam Majer
2023-04-05 20:01 ` Jeff King
2023-04-05 20:40 ` Junio C Hamano
2023-04-05 21:15 ` Junio C Hamano
2023-04-05 21:26 ` Jeff King
2023-04-05 22:48 ` brian m. carlson
2023-04-06 13:11 ` Adam Majer
2023-04-25 21:35 ` brian m. carlson
2023-04-25 22:24 ` Junio C Hamano
2023-04-25 23:12 ` Junio C Hamano
2023-04-26 0:20 ` brian m. carlson
2023-04-26 11:25 ` Jeff King
2023-04-26 15:08 ` Junio C Hamano
2023-04-26 15:13 ` [PATCH] doc: GIT_DEFAULT_HASH is and will be ignored during "clone" Junio C Hamano
2023-04-26 21:06 ` brian m. carlson
2023-04-27 4:46 ` git clone of empty repositories doesn't preserve hash Jeff King
2023-04-26 10:51 ` Jeff King
2023-04-26 15:42 ` Junio C Hamano
2023-04-26 20:40 ` brian m. carlson
2023-04-26 20:53 ` [PATCH 0/2] Fix empty SHA-256 clones with v0 and v1 brian m. carlson
2023-04-26 20:53 ` [PATCH 1/2] http: advertise capabilities when cloning empty repos brian m. carlson
2023-04-26 21:14 ` Junio C Hamano
2023-04-26 21:28 ` brian m. carlson
2023-04-27 5:00 ` Jeff King
2023-04-27 5:30 ` Jeff King
2023-04-27 20:40 ` Junio C Hamano
2023-04-26 20:53 ` [PATCH 2/2] Honor GIT_DEFAULT_HASH for empty clones without remote algo brian m. carlson
2023-04-26 21:18 ` Junio C Hamano
2023-04-26 21:33 ` Junio C Hamano
2023-04-27 5:43 ` Jeff King
2023-05-02 23:46 ` Is GIT_DEFAULT_HASH flawed? Felipe Contreras
2023-05-03 9:03 ` Adam Majer
2023-05-03 15:44 ` Felipe Contreras
2023-05-03 17:21 ` Adam Majer
2023-05-08 0:34 ` Felipe Contreras
2023-05-03 9:09 ` demerphq
2023-05-03 18:20 ` Felipe Contreras
2023-05-03 22:54 ` brian m. carlson
2023-05-08 2:00 ` Felipe Contreras
2023-05-08 21:38 ` brian m. carlson
2023-05-09 10:32 ` Oswald Buddenhagen
2023-05-09 16:47 ` Junio C Hamano
2023-04-26 21:12 ` [PATCH 0/2] Fix empty SHA-256 clones with v0 and v1 Junio C Hamano
2023-04-27 4:56 ` Jeff King [this message]
2023-05-01 17:00 ` [PATCH v2 0/1] " brian m. carlson
2023-05-01 17:00 ` [PATCH v2 1/1] upload-pack: advertise capabilities when cloning empty repos brian m. carlson
2023-05-01 22:40 ` Jeff King
2023-05-01 22:51 ` Junio C Hamano
2023-05-01 17:37 ` [PATCH v2 0/1] Fix empty SHA-256 clones with v0 and v1 Junio C Hamano
2023-05-17 19:24 ` [PATCH v3 " brian m. carlson
2023-05-17 19:24 ` [PATCH v3 1/1] upload-pack: advertise capabilities when cloning empty repos brian m. carlson
2023-05-17 21:48 ` [PATCH v3 0/1] Fix empty SHA-256 clones with v0 and v1 Junio C Hamano
2023-05-17 22:28 ` brian m. carlson
2023-05-18 18:28 ` Jeff King
2023-05-19 15:32 ` brian m. carlson
2023-04-05 21:23 ` git clone of empty repositories doesn't preserve hash Jeff King
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=20230427045643.GB982277@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=adamm@zombino.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sandals@crustytoothpaste.net \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).