Best practice for setting the base commit position

[bigbearzhu]

I noticed that GitInfo supports 3 different ways of getting the base commit position.

1. The last commit GitInfo.txt has changed.
2. If GitInfo.txt doesn't exist, the last commit current branch fork from GitDefaultBranch or GitCommit.
3. If no valid fork point could be found, the last tag from the current branch or GitBaseTag.

We are using workflow that we work on master branch and only branch close to the release date. I'm thinking about what would be the best way to use GitInfo.

We want to rely on the version from GitInfo.txt. Then that means we have to have the file from the start of the master branch and update it after each branch has been created. Is there a way to specify which commit as the base commit, like the GitDefaultCommit, but not editing csproj files. We have lots of projects so changing the files after each branch is not ideal. Can it be read from a file like GitInfo.txt?

[kzu]

Well, the way I typically use it is by just updating GitInfo.txt (or any file name you choose, since you can provide a different $(GitVersionFile) name, see https://github.com/kzu/GitInfo/blob/master/src/GitInfo/build/GitInfo.targets#L30) right after branching, which is the point where you can decide what the version # will be for that branch

[kzu]

Also, @bigbearzhu you can have multiple GitInfo.txt files in a repo. The version will be calculated relative to the number of commits since the base version declared in that file + all commits on it or any files within the directory where the file is.

Please do reopen if you have further questions on usage.

Thanks!