On 2023-12-11 at 15:32:52, Patrick Steinhardt wrote: > On Mon, Dec 11, 2023 at 06:57:25AM -0800, Junio C Hamano wrote: > > We have "no way to do so"? We have "not done so"? > > We have not done so until now, and we have no easy way to change this on > the server-side as the server is not controlled by us in the first > place. That leaves two options I can think of: > > - Try harder on the client-side, e.g. by trying to download the > gitconfig as you propose further down. I wonder whether admins would > typically block access to the config, but doubt they do. > > - Change the format of `info/refs` to include the hash format, as this > file _is_ controlled by us on the server-side. Doesn't help though > in an empty repository, where the file is likely to never have been > generated in the first place. > > So it seems like downloading the gitconfig is the only viable option > that I can think of right now. I mean, we can add an `info/capabilities` file with capabilities and assume the repository is SHA-1 without it. I'm fine with that approach as well, and it can be implemented as part of `git update-server-info` pretty easily. But yes, absent that approach or parsing the config file, we'll have to just use the default settings. > > The simplest "fix" might be to leave what happens in this narrow > > case (i.e. cloning over dumb HTTP from an empty repository) > > undefined by not testing (or not insisting on one particular > > outcome), but ... > > I would be fine with that outcome, as well. It's not like the current > behaviour is correct in all cases either. The only benefit of that > behaviour is that a user can in fact work around the broken cases by > setting `GIT_HASH_DEFAULT` to the correct hash, and that benefit would > be retained by the diff I sent that made remote-curl.c aware of this > environment variable. That would also be fine with me. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
