Issue with GitIsDirty and GitCache

[annerajb]

I found a issue with a Solution with two projects using gitinfo.
They would fail on the String replace of the GitIsDirty while using the Git Cache file.
I suspect this is because the Variable GitIsDirty is not saved inside the gitcache text file and when applying the string substitution of the assembly file it would not replace it since it didn't find it.

I had to workaround it by always using GitSkipCache

[kzu]

That should be a change around https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.targets#L775 (cache writing), https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.targets#L319 (cache reading) and https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.cache.pp#L3 (cache file file format).

Contributions are welcomed. Thanks!

[freza-tm]

While working on a #156 I came to conclusion that the GitIsDirty cannot be cached as there is no way to invalidate the cache (cache invalidation depend on content of .git folder) and have to be queried on every build to be correct. Am I right?

[freza-tm]

From my investigation, if I add the GitIsDirty to message in GitInfoReport task the output is correct for situation when moving from clean to dirty working directory. Unfortunately the task generating the source file is skipped with message "Target "GitVersion" skipped. Previously built successfully." This is in my opinion caused by input files containing only links to .git folder and there is nothing that changes with uncommited (unstaged) work. I'm not that strong with Msbuild to find workaround for this problem

[fabianoriccardi]

Hi, I think my question is related to this issue:

when I commit or make modifications, very often the IsDirty flag doesn't update (however other info always updates after the rebuild). Is it a way to make sure that this flag properly updates?

[kzu]

See #60 (comment). I don't really understand the usage of this property, it's there just because (IIRC) someone suggested it, but I've never had to use it for anything and I can't really think of a scenario where it would be useful for anything, honestly. Which is why it's super low priority for me to spend any time trying to fix this issue.

But I'll happily accept a PR that fixes it, of course :)

[freza-tm]

It is useful to mark the binary built on local machine with uncommited changes

[fabianoriccardi]

Exactly, and it is also good feedback to be sure you are building and deploying with a clean working directory.

[kzu]

I version my locally built packages with a fixed number always, like 42.42.42, and CI always builds clean. So, again, I personally have no use for this feature. Happy to take a PR if this is important to you.

You could also opt to sponsor the project and that would bump the priority (see available tiers for that).

Thanks