Re: discussion: sha1/sha256 repositories and convert_commit_object

[Adam Majer <adamm@zombino.com>]

On October 22, 2026 1:21:20 a.m. GMT+03:00, "brian m. carlson" <sandals@crustytoothpaste.net> wrote:
>On 2026-10-21 at 17:37:13, Adam Majer wrote

>I had noticed that the mergetags were not in Linus's repository, but I
>hadn't tried other repositories on kernel.org.

There is about a dozen or so mertags that I cannot find their objects. They have references to other repos, but trying those, they remained unresolved. One mergetag had some 3rd party url, which wasn't working, but http:// access allowed me to resolve it. One from a dozen missing resolved. 



>> Would it be possible to have a little different approach? For example,
>> mergetag headers and other unknown headers, maybe we can consider these as
>> just text and copy verbatim in convert_commit_object? I understand this
>> would result in different commit ids, depending if coming originally from
>> sha256 or sha1 repo, but since git is not really preserving references to
>> these objects anyway, this may call for a little flexibility.
>
>I don't think I converted mergetag entries in my original series.  The
>problem is that if we don't convert them, then we also can't validate
>them because we don't know what data they point to.  We don't make
>assumptions based on the size of the hash because in the future we might
>also have SHA3-256 or BLAKE2b-256.

I'm not sure that is quite correct. Any supported hash function should be unique enough such that we can just try all of them. So, a mergetag or proprietary headers, if we just treat them as text in conversion function, they can be retrieved later using the original function. Hash function doesn't matter for their existence or validity. I'm assuming here that the original repo containing them is not replaced in the meantime.

Basically, I'm assuming that a repo url keeps their original hash function.

The most important part here is to be consistent. These shouldn't be converted when available and skipped otherwise, or history becomes nondeterministic and depends on ingenuity of converting person to find these objects. 


>That means that the original point of the mergetags, to preserve the
>signature and contents of the original tag, would be useless.  That
>doesn't mean we couldn't skip converting them, but it does mean that if
>we do so, we should probably just stop writing those headers because
>they're no longer fit for purpose and we should consider them a failed
>implementation.

My problem is these mergetags have url where they were published. But they are quite missing on the git. kernel.org in these repos.

We can still convert the objects, but references would go via loose object table.


As for unavailable submodules, like in NodeJS repo from over a decade ago, I think they'll be unconvertible. It's not really possible to skip these without making a mess of history. Or perhaps you have an idea here? 

- Adam