-
-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error in ManagedGit when dealing with non-packed lightweight tags #1026
Comments
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 |
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 sshnet/SSH.NET#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:
Nerdbank.GitVersioning/src/NerdBank.GitVersioning/ManagedGit/GitRepository.cs
Line 782 in 549f6f4
and it comes from
Nerdbank.GitVersioning/src/NerdBank.GitVersioning/ManagedGit/GitRepository.cs
Line 657 in 549f6f4
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 line1.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.Footnotes
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. ↩The text was updated successfully, but these errors were encountered: