Re: git clone of empty repositories doesn't preserve hash

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 5, 2023, 19:04 UTC
Message-ID: <xmqqr0syw3pe.fsf@gitster.g>
In-Reply-To: <e7a8957e-6251-39f1-5109-87d4dd382e81@zombino.com>

Adam Majer <adamm@zombino.com> writes:

Show 15 quoted lines

> I've noticed while adding support for sha256 repositories for Gitea that,
>
> git init --bare --object-format=sha256 a
> git clone a b
>
> Then the repository b is initialized as default hash, so sha1. It
> seems that receive-pack will list the null OID in the header if there
> are no refs available, but the upload-pack doesn't list anything and
> hence the header with capabilities and the hash function is missing
>
> git receive-pack a
> git upload-pack a
>
> What is the right approach here? Could upload-pack send a NULL OID
> followed by header info that is then used by clone?

Interesting.

Does such a clone copy the name of the primary branch from the remote repository to the newly created repository? I recall we had seen such a feature request but offhand I do not recall how we solved it. The need to transmit a capability even when there is no concrete reference to be fetched to satisfy such a feature request should be the same as yours, so there may already be a good place to add that information. Or we may have ended up not solving the "what is the name of the primary branch in this empty repository?", in which case, the solution for this "what is the hash function to be used in this empty repository?" should be designed to be extensive enough to allow us later support that feature easily.

Thanks for raising the issue.