Expose various information from git through MSBuild variables

[cidzoo]

I'm aware of #758 that discusses how to embed git commit SHA into the <InformationalVersion>. In this discussion Microsoft.SourceLink is mentioned, but it's a very limited use-case that will work only for the commit SHA, right? Also I would avoid relying on any CI to set some envvars to provide the extra informations.

Also the idea would be a bit different than directly embed a SHA or another info into the version. Instead I'm thinking more about setting some MSBuild variables that could then be used by some MSBuild targets if needed to customize the version. For thoses who are familar it's what GitInfo do here.

From my understanding it's not a flow that is currently in place within MinVer, MSBuild variables are only used as input to configure the versionning. Correct me if I'm wrong. So this would need a flow to create some output variables, that one could, optionnally use to customize the versioning.

Here is an example of what I'm currently doing in my projects to give you a example:

<Target Name="AfterGitInfo" AfterTargets="GitInfo">
  <!-- Create a branch slug compatible with nuget -->
  <PropertyGroup>
    <GitBranchSlug>$([System.Text.RegularExpressions.Regex]::Replace($(GitBranch), '[^\w]+', '-') )</GitBranchSlug>
  </PropertyGroup>
  <!-- MinVer config -->
  <PropertyGroup>
    <MinVerDefaultPreReleaseIdentifiers>$(GitBranchSlug)</MinVerDefaultPreReleaseIdentifiers>
  </PropertyGroup>
</Target>

So here GitBranch is set by GitInfo and then used for MinVer versioning. But I need a reference only for that and don't use the versionning of GitInfo. So I'd rather rely only on MinVer to be able to customize the version in such way.

In the example above, it may not be a common use case where I use the branch to customize the pre-release id. However, I think it's pretty common to add git branch and/or hash to the build metadatas, etc. So it would probably be a great addition to the already excellent MinVer!

[adamralph]

I prefer to follow the UNIX philosophy:

Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.

For MinVer, the "one thing" is determining the version for a commit based on the last tag in the history. The name of the currently checked out branch in the working directory has nothing to do with that, so providing that would be a very distinct "second thing" for MinVer to be doing.

But as you've shown, there is something that does that—GitInfo. And because they both produce and consume the values of MSBuild properties, they work together and can be composed into a higher level use case such as the one you've shown.

If GitInfo does more than that one thing, and that causes problems, then it's not following the same philosophy and it's a good demonstration of why that causes problems. But maybe there's another package that does follow the same philosophy? Or maybe that's your next package? 😉

[cidzoo]

Ok thanks. I get your point and I think it's relevant.

On the other hand, I still believe it's a pretty common usecase to use branch name slug or SHA in build metadatas. Having to rely on CI or other libraries solely for this purpose is a bit of a shame. Especially knowing that everything is already available internally to retrieve such infos within this tool/library.

Anyway, I guess it's a matter of opinion 😌 Namely finding the sweet spot between doing only "one thing" while providing enough and/or related functionalities.

[adamralph]

Focusing on the specifics:

Branch name—MinVer doesn't read the branch name. It has no use for it. So this is clearly outside its scope. You can easily get this from most CI systems as an environment variable.

Commit SHA—the .NET 8 SDK provides this as SourceRevisionId.