-
-
Notifications
You must be signed in to change notification settings - Fork 167
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
Version height calculated differently in 3.4 with new git backend #658
Comments
Ooh, that doesn't sound good. Sorry about the package version overwriting. That sounds terrible. Can you share your git history / repo so we can use it to study the problem? |
Hey thanks for the quick reply. Sorry, I can't share the repo itself, but I'll try to give as much context as possible. |
Thank you. Do you think you could try creating a new repo with a similar path and history structure (no need for 1000s of commits -- just enough to represent the history of the version.json file and perhaps a dummy file in the project dir) to see if you can repro it on a repo you can share? |
Ok I took the time and thankfully it was fairly easy to reproduce. All you apparently need is a merge commit with relevant changes in both parents. If you clone this repo: https://github.com/nmeyering/nbgv-bug-repro and run
you should see the output differs. |
I have written a unit test to repro the issue using your shared repro as a template. Thank you. I'm investigating a fix. |
The managed git implementation had it correctly implemented, according to the code comments in the libgit2 implementation. But those code comments did not match the *code* in the libgit2 implementation. As a result, the managed git code did not match. In this commit I correct the libgit2 impl code comments to describe what the code *actually* does. Then I fix the identical code comment and code in the managed git implementation to match. Fixes dotnet#658 (cherry picked from commit 96be5aa)
It seems git version height still yields different results with the new git backend in some cases. This tripped us up because it meant old packages were being overwritten with new ones, causing chaos in our dependency graph.
Seems to be different from #587 since we get a non-zero version and it still happens in
3.4.231
?and with the old git backend:
Nbgv version 3.3.37 yields
1.0.49
also.The
version.json
file is:The text was updated successfully, but these errors were encountered: