Closed Rob-Hague closed 8 months ago
Thanks for your report. You seem to know quite a bit about this and are comfortable looking through the code. How would you feel about authoring the fix?
I didn't write the ManagedGit implementation, so I have to be very careful with anything I change there.
CC: @filipnavara @georg-jung in case either of them want to take a crack at fixing this.
Thanks for the detailed description. I think the general assessment of the situation is correct and it would work correctly if TryGetObjectByPath
returned false
instead of throwing exception. Unfortunately I am quite busy at the moment to submit a PR with appropriate tests.
Thanks, I'll try it out on the weekend
@AArnott Any chance a new pre-release could be generated? We believe this is causing an issue for us but would like to verify.
Realized we can use Nerdbanks public feed, but think it would also be cool to get some of the recent changes into a pre-release and future official release
Yes. 3.7.62-alpha is going to nuget.org now.
I am trying to build https://github.com/sshnet/SSH.NET/pull/1299 in my local fork. The repo has some tags which are lightweight tags e.g. 2023.0.0. The build fails locally with
The problem appears to be that ManagedGit is assuming the object is of type "tag" (annotated) whereas it is of type "commit" (lightweight). The error is here:
https://github.com/dotnet/Nerdbank.GitVersioning/blob/549f6f4ed81ac37dc7be2968690fec9904e87e08/src/NerdBank.GitVersioning/ManagedGit/GitRepository.cs#L782
and it comes from
https://github.com/dotnet/Nerdbank.GitVersioning/blob/549f6f4ed81ac37dc7be2968690fec9904e87e08/src/NerdBank.GitVersioning/ManagedGit/GitRepository.cs#L657
The reproduction is a little convoluted because there is no error on a fresh clone with .pack files, and it also requires the tags to be "unpacked" (in .git/refs/tags rather than in .git/packed-refs). That's because of the
!isPeeled
check in the above line[^1].Arguably these tags should be annotated, but supposing it makes sense to consider lightweight tags in this process, perhaps
TryGetObjectByPath
should be returning false rather than throwing (likeGitPack.TryGetObject
effectively seems to do), and then things should work correctly? I don't know how this logic fits into the wider process.[^1]:
isPeeled
comes from theout
parameter ofEnumeratePackedRefsRaw
and relates to the packed-refs file as a whole rather than whether a particular object is peeled. That doesn't seem intuitively right but then I don't know anything about peeling.