_git2_ junction directory is throwing off dirty checks

[AArnott]

After dotnet/Nerdbank.GitVersioning#393 upgraded libgit2sharp from 0.27.0-preview-0007 to 0.27.0-preview-0024, tests and scenarios started failing because libgit2sharp's dirty checks reported an uncommitted file with a _git2_ prefix. It actually looks like a directory junction. It's causing Repository.RetrieveStatus().IsDirty to return true and the RepositoryStatus.Untracked collection to be non-empty.

If this new _git2_ directory is a required temporary location for opening the repo, can libgit2sharp be taught to ignore it for all such purposes?

[AArnott]

I worked around this in a test here but it will be more complicated to fix this one.

[ethomson]

If this new git2 directory is a required temporary location for opening the repo, can libgit2sharp be taught to ignore it for all such purposes?

When libgit2 learned how to deal with symlinks on Windows (core.symlinks = true), it started examining the working directory to see if symbolic links were supported.

Regrettably, we didn't clean up this test symlink correctly immediately, but this was fixed.

I'd encourage LibGit2Sharp to do an update to a newer libgit2 binary.

Regrettably, LibGit2Sharp is basically cruising without a lot of labor. I'm not working on it anymore, and @bording recently indicated that he's quite busy. This is realistically easy enough that I can carve out some time to deal with it, but @AArnott, if you had time and / or the inclination to do the update then that would be 👍 as well.

[AArnott]

Hmmmm... I'm not sure I'm ready to run into being a maintainer. I may need to sooner or later.
In the meantime, is there some version between 0007 and 0024 that gives me worktree support but doesn't add the buggy symlinks support?

Otherwise, is there a write-up anywhere of how to take an update of libgit2 binaries all the way through the nativebinaries package and to the libgit2sharp package?

[ethomson]

Otherwise, is there a write-up anywhere of how to take an update of libgit2 binaries all the way through the nativebinaries package and to the libgit2sharp package?

Kinda, sorta, not really. https://github.com/libgit2/libgit2sharp.nativebinaries has a README that sort of explains it, but not entirely and too completely to be really useful.

I just looked 👀 and I think that there's Another Issue, which is that there's no libgit2 release that actually has this fix yet. In ye olde days, we would just grab a random commit into LibGit2Sharp, but we started actually pinning it to libgit2 releases which is nice in a lot of ways except that we haven't even done a point release lately.

In any case, I can probably find some time tonight to do something here and write up the process.

[AArnott]

Thanks. I am willing to try the process to see if I can help share the load of shipping these updates when you have written as much documentation as you can and/or can respond to my questions as I go along.

Given there hasn't been a libgit2 release with the fix, that brings me back to the possibility of downgrading in the meantime. Is there some version between 0007 and 0024 that gives me worktree support but doesn't add the buggy symlinks support?

[bording]

Otherwise, is there a write-up anywhere of how to take an update of libgit2 binaries all the way through the nativebinaries package and to the libgit2sharp package?

There is a script you can run in the native binaries repo that will update the version of libgit2 that is used, and then there is another script that will actually pull all the artifacts together into a single package.

So it sounds like the first thing would be to get a libgit2 update with the fix out, and then we can pretty quickly update the native binaries package.

Once that is on nuget.org, it's just a matter of updating LibGit2Sharp to use it.

[ethomson]

@AArnott check out https://www.nuget.org/packages/LibGit2Sharp/0.27.0-preview-0029, this should solve your problem

[AArnott]

Thanks! That worked.