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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adam Majer <adamm@xxxxxxxxxxx> writes:

> 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux