Nerdbank.GitVersioning: GitException: An object of type commit could not be located at offset 60529
Nerdbank GitVersioning has been working for a couple of years with Gitlab (On-site hosted). We recently upgraded our .net projects from aspnet core 3.2 to .net 6. and Gitlab has not changed, but we are now seeing issues compiling.
We now see an exclamation icon in Visual Studio 2022 under the dependencies section for NerdBank.GitVersioning (3.5.109) We also get the following error when trying to compile:
Error MSB4018: The "Nerdbank.GitVersioning.Tasks.GetBuildVersion" task failed unexpectedly.
Nerdbank.GitVersioning.GitException: An object of type commit could not be located at offset 60529.
at Nerdbank.GitVersioning.ManagedGit.GitPackReader.GetObject(GitPack pack, Stream stream, Int64 offset, String objectType, GitPackObjectType packObjectType)
at Nerdbank.GitVersioning.ManagedGit.GitPack.GetObject(Int64 offset, String objectType)
at Nerdbank.GitVersioning.ManagedGit.GitPack.TryGetObject(GitObjectId objectId, String objectType, Stream& value)
at Nerdbank.GitVersioning.ManagedGit.GitRepository.TryGetObjectBySha(GitObjectId sha, String objectType, Stream& value)
at Nerdbank.GitVersioning.ManagedGit.GitRepository.GetObjectBySha(GitObjectId sha, String objectType)
at Nerdbank.GitVersioning.ManagedGit.GitRepository.GetCommit(GitObjectId sha, Boolean readAuthor)
at Nerdbank.GitVersioning.Managed.GitExtensions.<GetCommitHeight>g__TryCalculateHeight|4_0(GitCommit commit, <>c__DisplayClass4_0& )
at Nerdbank.GitVersioning.Managed.GitExtensions.GetCommitHeight(GitRepository repository, GitCommit startingCommit, GitWalkTracker tracker, Func`2 continueStepping)
at Nerdbank.GitVersioning.Managed.GitExtensions.GetHeight(ManagedGitContext context, Func`2 continueStepping)
at Nerdbank.GitVersioning.Managed.GitExtensions.GetVersionHeight(ManagedGitContext context, Version baseVersion)
at Nerdbank.GitVersioning.Managed.ManagedGitContext.CalculateVersionHeight(VersionOptions committedVersion, VersionOptions workingVersion)
at Nerdbank.GitVersioning.VersionOracle..ctor(GitContext context, ICloudBuild cloudBuild, Nullable`1 overrideVersionHeightOffset)
at Nerdbank.GitVersioning.Tasks.GetBuildVersion.ExecuteInner()
at MSBuildExtensionTask.ContextAwareTask.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() (18, 6)
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (4 by maintainers)
I’ve used the zip file that I previously shared. It was able to reproduce the problem with version
3.5.109
, but3.6.42-alpha-g47b0d281e4
seems to be working fine.PS: I’m using
dotnet 7.0.100-preview.6.22352.1
for my tests.Hi @AArnott,
I’ve managed to reproduce the problem by building a git repo with a synthetic commit history. It appears to me that managed engine has some problems with reading data from pack streams, but I didn’t get to the bottom of the problem yet. I can see in the debugger, that occasionally the read operation returns fewer bytes than requestd (
read != toRead
) in https://github.com/dotnet/Nerdbank.GitVersioning/blob/efc3b4c6f005530d0576d79f16ae93b3bb62d512/src/NerdBank.GitVersioning/ManagedGit/GitPackMemoryCacheStream.cs#L87Thanks for the update. Maybe your repo was corrupted. But it’s still possible that in working with your repo that an object is created that we can’t parse (but git.exe can). If this re-surfaces for you again, please let us know.
The version of VS you’re using is probably irrelevant, and what you do within the repo is certainly irrelevant. It’s all about the git.exe you used to clone and maintain the repo, and perhaps the git operations you perform within that repo. I couldn’t say why one clone you have works and another doesn’t other than to say that the git db has multiple ways to store objects (e.g. loose files vs. pack files) and only one of these ways is causing the trouble.
Then I imagine it’s just a newer git version that changed the format, or perhaps a format that was always there but is unusual so our managed git implementation didn’t need to support it until now. Hopefully @qmfrederik (who wrote our managed git implementation) can investigate.