On Wed, Apr 26, 2023 at 09:28:31PM +0000, brian m. carlson wrote:
> > > However, this does pose a problem when working with SHA-256
> > > repositories, since we use the capabilities to know the remote side's
> > > object format (hash algorithm). It used to be possible to set the
> > > correct algorithm with `GIT_DEFAULT_HASH` (which is what the Git LFS
> > > testsuite did), but this no longer works as of 8b214c2e9d ("clone:
> >
> > "this no longer works as of" -> "this was a mistake and was fixed by".
>
> I tend to disagree. While I agree that change is valuable because it
> fixes v2, which we want, it does cause a change in user-visible
> behaviour, which broke the Git LFS testsuite. Whether we like things
> working that way or not, clearly there were people relying on it.
>
> Fortunately, in that case, Git LFS can just enable protocol v2 and
> things work again, but I think "this no longer works" is accurate and
> more neutral, and addresses the issue. We wouldn't have to deal with
> that issue if we could gracefully handle git clone --local with older
> versions of the protocol, but one of the tests fails when we do that.
> I'll take some more time to see if I can come up with a nice way to
> gracefully handle that, and if so, I'll send a v2.
Reiterating what I said upthread, I think it was always 50% broken.
Taking the local hash format over the remote one was always the wrong
thing to do, but it sometimes worked out (because we happened to match
the remote).
But the opposite case:
git init --object-format=sha1 dst.git
GIT_DEFAULT_HASH=sha256 git clone dst.git
would previously have done the wrong thing. We just flipped which half
was broken and which was not.
-Peff
