Nerdbank.GitVersioning: GIT alternates not supported with version 3.4x

When repository is checked out with GIT alternates (e.g. as TeamCity does) NBGV get-version fails: Nerdbank.GitVersioning.GitException: An commit object with SHA 163380e3fa79d36c0e51efc251132aa7e7f86b9d could not be found.

To reproduce: _git clone --mirror https://github.com/dotnet/Nerdbank.GitVersioning.git_ git clone --shared --reference .\Nerdbank.GitVersioning.git https://github.com/dotnet/Nerdbank.GitVersioning.git test cd test nbgv Get-Version

I’m using NBGV v3.4.194 on Windows. Setting NBGV_GitEngine=LibGit2 works but unfortunately not in Docker image mcr.microsoft.com/dotnet/sdk:5.0 because of dependency load problems for LibGit2.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 20 (8 by maintainers)

Most upvoted comments

whoops… I feel like an idiot 😄 Thanks @AArnott , that was the problem indeed.

changing the step to:

- name: Checkout repository
      uses: actions/checkout@v3
      with:
        fetch-depth: 0

did it

@3x0dv5 Your fetch-depth is 1: https://github.com/ruilimacom/amiliur.annotations/actions/runs/4823851800/jobs/8592878009#step:2:8

You need to set fetch-depth to 0 so that history is downloaded.

@qmfrederik Prerelease v3.4.203 works on Linux host with Linux container!

Altough GIT height is always zero (https://github.com/dotnet/Nerdbank.GitVersioning/issues/587)

@AArnott By the way, from a conversation on another project:

As long as there is no native dependency (that’s bugged me a lot), and that it’s fast… One issue I had with one of the gitversion tools was that it recalculated the version for each project in a solution (hence my tendency to calculate versioning once and apply it by includes)… Minver has yet to show the same slowness.

Performance and portability seem to be a common concern for users of git-based versioning tools in the ecosystem. Glad to see nbgv making progress on both fronts!

Thanks, @AArnott . I had a look at two issues which seemed straightforward (including this one). Issues like #584 and #587 will probably need more time. Do you think you could label issues related to the managed git implementation with a managed-git label or something similar? That would help me identify those.

There was some work done to support alternates, e.g. https://github.com/dotnet/Nerdbank.GitVersioning/blob/master/src/NerdBank.GitVersioning/ManagedGit/GitRepository.cs#L537-L568 (and in the constructor), but obviously it fails here.

I’ll try to free up some time to have a look at the open managed-git issues (this one seems easy to reproduce). (Unfortunately, freeing up time is not so easy lately).