Enable config based ignoring of commits/messages that incorrectly inc…

[Sacrelicious]

…rement version

The latest changes to the MergeMessage branching strategy, while very
helpful, have pulled in very old messages from our repo that are
formatted in a way that cause the version number to be unexpectedly
high.
This changes allows configuration of commit SHAs to ignore, or strings
to ignore inside merge messages, so you can "fix" old commits in your
repo that you don't want to effect the version generation.
This is related to #466 and a possible fix for #443

[JakeGinnivan]

Wondering if we should do something a little more generic, what about bad tags or other things? Thoughts?

[Sacrelicious]

My thought on tags specifically is that it's pretty easy to delete/fix a bad tag, but fixing a bad commit/message from way back in the repo is nigh on impossible.

As to the larger point, how do you think that would be accomplished? Just have a ThingsToIgnore collection and just do

if(mergeCommit.Sha.In(ThingsToIgnore) || mergeCommit.Tag.In(ThingsToIgnore) || ... etc. etc.)

?

I'm not super familiar w/ how the Commit object works, so there might be a better way than that.

[JakeGinnivan]

That's true. Leave me with this, want to think it through before I put it in the config (cause then we are stuck with it).

I will merge this before the next release.

[Sacrelicious]

Sounds good!

[JakeGinnivan]

I am wondering if we should add something to the gitversion init helpers. Something along the lines of:

• Solve GitVersion generating the wrong version? ->
• Ignore a particular commit or merge message:
  • List the discovered base merge messages.
• Choose to ignore one, it adds the config

Recon it's worth it?

[JakeGinnivan]

I can help out with the init stuff if you think it would be worth it

[JakeGinnivan]

I have been thinking about this. I think we should just have commits-to-ignore in the config.

Then in https://github.com/GitTools/GitVersion/blob/release/3.0.0/GitVersionCore/VersionCalculation/BaseVersionCalculator.cs#L24 add another if which checks to see if the Source on that base version matches any sha's in that config.

[Sacrelicious]

I'm not opposed to that, although I do have 2 caveats:

1. if the string that's incrementing the version incorrectly is part of a branch name, it could be in a number of merge messages (merged into a feature branch, then merged into develop, then into release, then into master) resulting in a bunch of commits that would need to be excluded to prevent 1 bad version name from being used.
2. (Unless I'm missing it) There would need to be more details available in logs/console about the commit the final version number is derived from so the user will know which commit(s) to exclude.

[Sacrelicious]

And I'm definitely all for doing something w/ the init stuff.

[JakeGinnivan]

Beta 4 has much better logs so it lists everything you would need.

Also the init configuration could have an option to exclude commits which are causing incorrect version bumps, one option could be to exclude commits with commit message. So config is simple and init has the options?

Sent from my Windows Phone

---

From: Chris Maffinmailto:[email protected]
Sent: ‎26/‎06/‎2015 22:51
To: GitTools/GitVersionmailto:[email protected]
Cc: Jake Ginnivanmailto:[email protected]
Subject: Re: [GitVersion] Enable config based ignoring of commits/messages that incorrectly inc… (#470)

I'm not opposed to that, although I do have 2 caveats:

1. if the string that's incrementing the version incorrectly is part of a branch name, it could be in a number of merge messages (merged into a feature branch, then merged into develop, then into release, then into master) resulting in a bunch of commits that would need to be excluded to prevent 1 bad version name from being used.
2. (Unless I'm missing it) There would need to be more details available in logs/console about the commit the final version number is derived from so the user will know which commit(s) to exclude.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/470#issuecomment-115900513.

[mauroservienti]

I just faced this while trying to add GitVersion to an existing repo with a legacy history. What happened is that existing TAGs were causing GitVersion to generate a wrong SemVer version.
In my scenario, an optimal setting would be something like IgnoreBeforeSHA XYZ.

[JakeGinnivan]

Ignore before a time would be better than a sha, otherwise it needs another scan of the repo to find all sha's which are before a specific sha. At least specific shas are a simple equality check.

[gep13]

👍 for ignore before a time.

[mauroservienti]

Time works for me as well

[asbjornu]

Some sort of ignore-before-* mechanism should solve the problem I've explained in #443, so getting something like that in v3 before RTM would be great!