switch from LibGit2Sharp to Git

[adamralph]

fixes #149
closes #269

Breaking changes (which are unlikely to break anyone):

• Introduces a dependency on Git
• Drops support for versioning from a Git directory. That is, the .git subdirectory of a working directory, or a bare repo.

[adamralph]

@bording it's a little hacky but it seems to work!

I don't think it will work for annotated tags yet. - works now

[adamralph]

@alexeyzimarev @bartelink @blairconrad @bording @damianh @enzian @g8rdev @leastprivilege @mauroservienti @Mpdreamz @Selmirrrrr @shaynevanasperen @slang25 @thefringeninja @yreynhout: as prolific MinVer users/contributors, do you see any pitfalls with this?

It runs the following Git commands:

1. git status --short - check whether the path is contained in a working directory
2. git log --pretty=format:"%H %P" - get the commit graph
3. git show-ref --tags --dereference - get the tags

All of these commands have been available since some point during the Git 1.x range, so they will all work in the 2.x range.

Unfortunately, I have to swallow exceptions when running 2 and 3 because I've found no way to determine whether they will succeed or fail before running them. For example:

• 2 fails in most versions of Git when there are no commits. In some versions, git rev-list --count will return 0 if there are no commits, so I can run that first, but in other versions (e.g. 2.11.0) it will also fail when there are no commits. 🙄
• 3 fails in most versions of Git when there are no tags. In some versions, git log --tags will return an empty string if there are no commits, so I can run that first, but in other versions (e.g. 2.11.0) it will return the commits regardless. 🙄

However, I believe swallowing exceptions and returning the default version is fine in both cases. For all the versions of Git I tried, git status --short, unsurprisingly, succeeds when the path is contained in a working directory, and fails when it is not. So if that has succeeded, I believe it's reasonable to assume that a failure of command 2 means "no commits" and a failure of command 3 means "no tags".

BTW - performance seems to be unaffected. I ran a local build against master on https:/dotnet/cli, which has ~12,000 commits, and it returned "instantly". Or at least, as fast as the current LibGit2Sharp-based MinVer.

[blairconrad]

Yeah, it's probably fine, right?

[bording]

Overall I think the concept is fine, and there are benefits in moving away from LibGit2Sharp.

This does mean you're taking an external dependency that you don't control, though. Sure, it seems reasonable to assume that git is on the path somewhere, but MinVer is currently self-contained.

[adamralph]

This does mean you're taking an external dependency that you don't control, though. Sure, it seems reasonable to assume that git is on the path somewhere, but MinVer is currently self-contained.

Yes, that gave me pause, but I think it's probably OK. If it is a problem, I expect it be shown during the alpha phase. I'll ensure an alpha is tested in all the cloud CI providers I can think of, and in Docker builds such as https:/SQLStreamStore/SQLStreamStore, but I'm optimistic that all those environments will have git in the path. I guess some container images may not have it, and in those circumstances, I guess bootstrapping Git will be required, which I don't think should be too much of a problem. And it's probably an edge case anyway. 🤞

[slang25]

I like the idea of libgit2sharp, however the reality doesn't live up. It's missing features, and the native binaries are problematic in many environments such as some docker images.

Assuming git in the environment makes sense here, and the implementation looks sounds :)

[damianh]

Wait, this won't work on my perforce repositories??

[damianh]

J/K, fine with this. The project had an hard dependency on git anyway.

[adamralph]

Released in 2.0.0-alpha.1.