GitRepository: Support additional upstream extensions

[sandyarmstrong]

Upstream git is actively working on extensions that should be treated as known, even if they are currently experimental, as they do not break these targets.

objectFormat and compatObjectFormat are used to support SHA256 hashes: https://git-scm.com/docs/hash-function-transition

refStorage is used to support the new reftable binary storage backend: https://git-scm.com/docs/reftable

These extensions offer performance and security benefits, and we should expect to see more users trying them out before they become the default in git 3.0.

See https://about.gitlab.com/blog/what-s-new-in-git-2-51-0/#planning-towards-git-30 for details about what may be coming in git 3.0.

Fixes #1097.

[tmat]

With SHA256 enabled, couldn't references now contain SHA256 instead of SHA1, which would result in an exception thrown when we read these?

[sandyarmstrong]

With SHA256 enabled, couldn't references now contain SHA256 instead of SHA1, which would result in an exception thrown when we read these?

I thought the target just reads them as strings?

[philipp-naused]

Could you add relativeWorktrees as well?
https://git-scm.com/docs/git-config#Documentation/git-config.txt-relativeWorktrees
For #1468

[tmat]

Some code changes are needed to handle the new file formats:

E.g.
https://github.com/dotnet/sourcelink/blob/main/src/Microsoft.Build.Tasks.Git/GitDataReader/GitReferenceResolver.cs#L258

We also need tests for each of these.

[sandyarmstrong]

For the reftable format, we might ideally want a libgit2sharp that understands how to work directly with that backend. Looks like libgit2 folks are currently working on that: libgit2/libgit2#7117.

[sandyarmstrong]

For objectFormat (to support SHA256 hashes), even after bumping to the latest libgit2sharp, I see that branch rename in the integration tests fails due to LibGit2Sharp.LibGit2SharpException : unsupported extension name extensions.compatobjectformat.

But libgit2/libgit2#6191 explains that not supporting compatobjectformat is intentional, and makes the assertion that git itself does not yet support that either. I'll need to do some research to see if that is true. However, I have verified that if you run git init --object-format sha256 in git 2.51, it only sets objectformat (and repositoryformatversion), not compatobjectformat.

compatobjectformat aside, there are still errors as described in libgit2/libgit2sharp#2153.

[tmat]

For the reftable format, we might ideally want a libgit2sharp that understands how to work directly with that backend. Looks like libgit2 folks are currently working on that: libgit2/libgit2#7117.

We only use libgit2sharp for end-to-end testing. Source Link has its own git data reader.

[the-black-wolf]

@sandyarmstrong

For objectFormat (to support SHA256 hashes), even after bumping to the latest libgit2sharp, I see that branch rename in the integration tests fails due to LibGit2Sharp.LibGit2SharpException : unsupported extension name extensions.compatobjectformat.

But libgit2/libgit2#6191 explains that not supporting compatobjectformat is intentional, and makes the assertion that git itself does not yet support that either. I'll need to do some research to see if that is true. However, I have verified that if you run git init --object-format sha256 in git 2.51, it only sets objectformat (and repositoryformatversion), not compatobjectformat.

compatobjectformat aside, there are still errors as described in libgit2/libgit2sharp#2153.

compatobjectformat is not set by git-init. You have to set it by git-config. And as far as I know this works, not sure what libgit2 Edward is talking about (though this issue is from 2022, so that might explain it). Regardless, the SHA256 is definitely no longer experimental in Git, so dotnet tooling should update asap.