git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Adam Majer <adamm@zombino.com>
To: Patrick Steinhardt <ps@pks.im>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: SHA256 support not experimental, or?
Date: Fri, 30 Jun 2023 13:25:06 +0200	[thread overview]
Message-ID: <5880fe56-aa98-64ce-4d91-ca078d3a7354@zombino.com> (raw)
In-Reply-To: <vt3cizczmwbcpgktwrkr3jbiwhee37rt7m243hnkzxik7gt4m2@d2upsqoxtlgc>

On 6/30/23 11:31, Patrick Steinhardt wrote:
> Indeed, supporting SHA256 is a major effort on our side at GitLab. Most
> of the work isn't really adapting our production code, but it's rather
> that tons of tests were written with seed repositories and hardcoded
> object hashes. Converting all of that isn't all that hard in the general
> case, but it's a tedious job.

Hi!

This actually reminds me of a funny story from my side.

Earlier this year, I was testing various frontends and how they would 
handle SHA256 repositories. All of them failed, not surprising. I even 
managed to lock myself out of Gitlab by importing a SHA256 private repo 
into my home project -- every time this project became visible, it would 
result in Error 500 from the UI. Today (few weeks ago), this appears to 
be fixed -- the UI is just broken, so you can't see anything in sha256 
repository, but at least I was able to delete the project.

The repository was correctly imported and I could clone from gitlab, so 
the problem is mostly "just" UI. :-)

The most likely frontend we'll use for our internal project is Gitea. 
The sha256 support is in progress

https://github.com/go-gitea/gitea/pull/23894

 From the size of this patch, you can see how ingrained SHA1 assumption 
was. Most of the patch is just to remove the hardcoded elements, 
including hardcoded SHA1 empty-tree hashes and assumption that 20 bytes 
is enough to hold a hash. And I didn't even add sha256 test cases...

But I have to say that in at least one occasion, people are bringing up 
the experimental nature of git's sha256 support (per current wording) as 
reason not to make their tools sha256 compliant.

> In any case I'm fully supportive of relaxing the current warning. Except
> for the recently discussed edge case where cloning empty repositories
> didn't create a SHA256 repository I have found the SHA256 code to be
> stable and working as advertised. We should caution people that many
> services will not work with SHA256 yet though.

That is exactly true. But this is also chicken-egg problem. Services are 
not adapted for sha256 repositories because there is simply no demand 
for them. Only when people will start using sha256 repos, will there be 
some demand generated.

- Adam

  reply	other threads:[~2023-06-30 11:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 16:28 SHA256 support not experimental, or? Adam Majer
2023-06-29  1:59 ` brian m. carlson
2023-06-29 10:42   ` Adam Majer
2023-06-29  5:59 ` Junio C Hamano
2023-06-29 10:53   ` Adam Majer
2023-06-29 20:56     ` Junio C Hamano
2023-06-29 21:17   ` brian m. carlson
2023-06-29 22:22     ` Junio C Hamano
2023-06-30  1:21       ` brian m. carlson
2023-06-30  9:31         ` Patrick Steinhardt
2023-06-30 11:25           ` Adam Majer [this message]
2023-06-30 11:38             ` Patrick Steinhardt
2023-06-30 12:20             ` Son Luong Ngoc
2023-06-30 16:45               ` Junio C Hamano
2023-07-20 15:07 ` Adam Majer
2023-07-20 18:18   ` Junio C Hamano
2023-07-26 16:44     ` Junio C Hamano
2023-07-31 13:38     ` Adam Majer
2023-07-31 13:42       ` [PATCH] doc: sha256 is no longer experimental Adam Majer
2023-07-31 16:01         ` Junio C Hamano
2023-07-31 16:44           ` Adam Majer

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=5880fe56-aa98-64ce-4d91-ca078d3a7354@zombino.com \
    --to=adamm@zombino.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ps@pks.im \
    --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.
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).