[WIP] Allow skipping commits that don't contain changes relative to the project path.

[danielcweber]

Consider the following scenario:

• I have a solution (.sln) with multiple projects (.csproj) in subfolders.
• These projects each produce a nuget package.
• A version.json is present in the solution-folder.
• On a build server (DevOps), always the complete solution is built, resulting in a new nupkg for each project, even if there were only changes in one of the projects.

I want to have a new package version only for the projects that have had changes. Having a separate version.json in each subfolder obviously won't work since the git height will still increase each time. This PR is a proof of concept and work in progress to enable skipping commits that don't contain any changes for the directory of the project, thus excluding them from contributing to the git height. This is enabled by setting <SkipCommitsWithoutChangesInPath>true</SkipCommitsWithoutChangesInPath> in MsBuild.

The PR is in early stages, there are changes in signatures of public methods and I'm sure I missed a lot of code paths so that the new feature won't work in all cases. Depending on whether this change is considered useful, I will continue work on this.

[AArnott]

Thanks for contributing. Two quick thoughts, acknowledging I haven't yet seen your change:

1. Settings always go in the version.json file, since this will impact more than msbuild.
2. We probably want to consider cases where a change to a referenced project (transitively) also causes the version bump.

[danielcweber]

We probably want to consider cases where a change to a referenced project (transitively) also causes the version bump.

That's indeed not considered in my scenario. That adds some layers of complexity...

I'm considering whether my approach is so useful after all if cross-references are considered. Maybe it's advisable to split up solutions in that case.

[AArnott]

Maybe it's advisable to split up solutions in that case.

I appreciate your flexibility in thinking about how it could be implemented. That would indeed simplify it. However based on conversations I've had in #160, I think the primary use case includes projects within the same solution having unique version heights. Finding transitive P2Ps references for all projects is impossible, but for .NET SDK projects might be possible, but as it would depend on MSBuild insights it may be undesirable anyway. So counting P2Ps may just be a requirement we can't meet. I'll ask for a vote on #160 to see how folks react.

[japj]

So to summarize, we need a way to calculate which paths contribute to the git height.

1. for a fully isolated project (e.g. no project references), the project folder would be 'enough'

2. for a project with (ProjectReference) dependencies, the paths to the project references also contribute to the git height (and this might be recursive)

3. for projects that make use of "known MSBuild import hooks" (e.g. Directory.Build.props/targets) the folders with the import hooks contribute to the git height

4. and 3) will indeed depend on MSBuild insights.
   Perhaps a "first" version of this mechanism could just contain a manual option to specify which (toplevel) folder contributes to git height. That way it would be an opt-in (for those "that know what they are doing").

A next version of this logic could then be prototyped/worked on to see how "correct" it can be made with actual MSBuild logic?

[AArnott]

Ya, thinking about it more, I suspect a transitive walk along P2P refs is probably a non-starter for several reasons. Having the user explicitly specify the set of folders (allowing more than one) that contribute to the height is probably sufficient.