On 2023-04-25 at 23:12:15, Junio C Hamano wrote:
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > If nobody looks at this, I'll take a look tomorrow and hopefully send a
> > patch.  I just wanted to point this out to the list right away in the
> > interest of getting it noticed.
> 
> Thanks.  
> 
> The topic in question has been in 'master' for 2 weeks, since it was
> merged at 96f4113a (Merge branch 'jc/clone-object-format-from-void',
> 2023-04-11), and as I said, what your test demonstrates is not a
> regression caused by the topic but "was broken, did not get
> addressed, is still broken".  So it does not sound like it needs
> "right away" kind of attention.

In my case, the clone is over HTTP, so this may not be the ideal way to
reproduce it and it may need a better testcase, but it does bisect to
the patch above and it is new in master (and doesn't reproduce in
2.40.0).  Note that in our case in the Git LFS testsuite, we're using
GIT_DEFAULT_HASH=sha256.

I believe what is happening is that for some reason, the object-format
data in v0 and v1 is not being read properly, and so we're now setting
it to sha1 whereas before we were reading the value from the default
setting of the repository (sha256).

It very well may be that it's always been broken and this has just made
it obvious that it's broken, but I'll look tomorrow and probably send a
patch.  I don't think we should revert this change, but I do think we
need to fix it before 2.41, since I think it means right now that all
clones over protocol v0 and v1 end up with a SHA-1 repository.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA