On Wed, 13 May 2020 at 02:58, brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> ls-remote may or may not operate within a repository, and as such will
> not have been initialized with the repository's hash algorithm. Even if
> it were, the remote side could be using a different algorithm and we
> would still want to display those refs properly. Find the hash
> algorithm used by the remote side by querying the transport object and
> set our hash algorithm accordingly.
>
> Without this change, if the remote side is using SHA-256, we truncate
> the refs to 40 hex characters, since that's the length of the default
> hash algorithm (SHA-1).
Could we add a test that passes now but would have failed before?
> ref = transport_get_remote_refs(transport, &ref_prefixes);
> + if (ref) {
> + int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
> + repo_set_hash_algo(the_repository, hash_algo);
> + }
This will modify `the_hash_algo`. Quoting commit 78a6766802 ("Integrate
hash algorithm support with repo setup", 2017-11-12):
Add a constant, the_hash_algo, which points to the hash_algo structure
pointer in the repository global. Note that this is the hash which is
used to serialize data to disk, not the hash which is used to display
items to the user. The transition plan anticipates that these may be
different. We can add an additional element in the future (say,
ui_hash_algo) to provide for this case.
Don't we violate that here? Is it mostly luck that we can go on to list
what we want to list and that we will never write to disk based on
`the_hash_algo` being "wrong"(?)? Or am I missing something?
Martin
