Is the custom target 'InitializeSourceControlInformation' still needed in .NET8+?

[sobrinth]

Currently in the template for the Directory.Build.targets there is a custom target called InitializeSourceControlInformation (source). This generates the SourceRevisionId based on git describe.
Starting with .NET8 Source Link is included in the .NET SDK and populates the SourceRevisionId property with the full git revision hash.

There are some differences between the two behaviours. See the following example with a dirty worktree

• Before (with custom target): 0.0.1+750eb0ad*
• Source Link (w/o target): 0.0.1+750eb0ade1eaa96ec27657daa8e40fc13cb2474e

Do we still have the use-case for using 'our' specialized implementation?

[CaringDev]

If you don't need the dirty flag and are happy with the full hash, I see no problem in removing the custom target.
Personally, I'm team dotnet/sourcelink#869, i.e. I like the short version, esp. since we show that in various places even to users (e.g. for error reports) and they also work for the URLs.
I thought about truncating the SourceLink generated version but then I would still miss the dirty flag (which for us is important because we sometimes ship "EAP versions" to customers).
Given these arguments, would you still vote to remove the custom target? I see, that these are specific requirements though would be fine with removing that target (or hide it behind a flag).

[sobrinth]

I see the point and am also in team 'short version'. I see the use behind having the dirty flag in the hash when shipping early versions. We removed it for our project as we don't need that and see a noticeable build time reduction.
I don't see a need to remove the custom target. I just wanted to start this discussion / see what other opinions are.

[CaringDev]

For the record: what is a 'noticeable build time reduction'? Luckily, for me it doesn't seem to make any difference 🤷
This, however, reminds me of 45c7baa
Does this solve the build time issue for you?

[sobrinth]

I haven't done any real measuring / testing, so take these numbers with a grain of salt.
For our project: 1sln, 60projects, SDK 8.0.403, Release the build times are
With the target: ~17s (avg. over 10 runs)
Without the target: ~12s (avg. over 10 runs)
This comes out to a bit over 80ms / csproj in the solution. This really is not that much, but as we don't need the hash, we decided to take this time saving. I haven't really played around with having it only disabled in Debug builds, but that would probably also be a workable solution.