[proposal] Option to count only first-parent commits in increment

[philippe-sb]

My use case:

1. dev branch is the main
2. feature branches are merged into dev
3. a pull-request from dev into staging, then staging into prod is done to produce releasable versions
4. installable artefacts from dev, staging and prod are generated by CI and have the version+branch name in the file name
5. no 2 distinct commits can have the same version number
6. thus version should come from tags plus increment from tag

This action covers most of the needs,:

• major/minor from tag manually set on dev branch
• bump_each_commit to automatically ensure requirement 5

I found 2 limitations however:

1. the increment includes all the commits, so it grows much too fast. Using git log --first-parent would solves that
2. because the tag is on dev, the increment on prod, ie. the count of commits from git log ${tag_commit_on_dev} ..${head_commit_on_prod} after the merge dev->prod, goes back in time to include the commits of previous merge operations into prod (which indeed don't exist on dev, so git is correct, but it's not what I want)

So I added 2 features:

1. an option to count the increment on git log --first-parent (keeping also the full increment as it helps comparing the generation of the code between branches)
2. a limit on the git log to only include commits since the tag commit (for limitation 2)

Currently my code is unpolished and untested in cases outside my own, but if there were interest, I'd be happy to share it and work on it for inclusion.

Thanks for the useful tool!

[PaulHatch]

Hi @philippe-sb, thank you for this proposal and sorry it took a while to get back to you. I will need to look in a bit more detail and make sure there are no weird edge cases with different branching strategies, but on the face of it I don't see any problem including this.

I am planning to invest some time soon to work on a v6 release, I had planned to do this in combination with setting up some new CI/CD on a another personal project of mine, but it is taking me quite a bit longer to finish my other project than I expected. Hopefully in the near future I'll be starting on this.

[philippe-sb]

Tell me if you need more info, I'm going to try to make a clean PR for it (actually 2, the --first-parent and the --since)
In terms of weird edge cases, is the test coverage wide enough that not breaking the tests would be a good indicator?

[PaulHatch]

There is coverage on every issue/feature/bug and all the major scenarios, but obviously none of them will have the new option enabled so they wouldn't be able to catch anything here aside from things that fundamentally break the existing behavior. For this I'm specifically thinking of anything where someone could enable this and get caught by an unexpected version behavior due to some other merge or something. There's quite a lot of diversity in branching strategies out there, even if it is documented a lot of people won't read it or can't follow overly prescriptive branching rules.

For point 2, I see the issue you have though I am not sure I understand exactly how you plan to achieve this and identify your starting point? When does the tag come into play? In general when you enable bump_each_commit usually you are abandoning the use of tags for versioning (because otherwise you'd just use tags), though they do still work.

Thanks for your interest in making this contribution, I think this could be a good option for people who don't need to gate their releases after the fact.