-
Notifications
You must be signed in to change notification settings - Fork 650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit the number of commits searched in tags and merge commits #2148
Labels
Milestone
Comments
arturcic
pushed a commit
that referenced
this issue
Mar 6, 2020
Limit the number of commits traversed when trying to find version from tags and merge messages to 2 (each). Solves #2148
arturcic
pushed a commit
that referenced
this issue
Mar 6, 2020
andrewabest
added a commit
to OctopusDeploy/GitVersion
that referenced
this issue
Oct 8, 2020
This reverts commit 4f431b8.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Problem description
I noticed that running gitversion on a 5-year old, active codebase, I noticed that every time, TaggedCommitVersionStrategy and MergeMessageVersionStrategy were checking
evry single tag/merge message back until the beginning of time to figure out the correct increased version.
I figured this could not be necesasry.
I think this relates to #360, #1850, #1868.
TaggedCommitVersionStrategy
MergeMessageVersionStrategy
Discussion
I have created a PR which "solves" the problem by taking only the 2 last tags/merge messages when trying to figure out the version. This seems a bit random.
Why not 1? Why not 10? Why not 50? If I take just 1, a unit test fails. But 2 makes all tests pass. Is this just a coincidence? Could we think of a scenario
where we would need 3? 5? or more? If so, are these very contrieved scenarios, so we should default to 2, and let it be configurable via a command-line option?
I am very humble as I don't always understand exactly all the rules GitVersion uses to figure out the versions. So I'd like some input on whether this fix
is madness or it actuelly makes sense.
Below are some measurements on some scenarios on my box and my repo (YMMV, of course).
Before fix:
Release branch:
Develop (a couple of weeks development ahead of master)
master
Long-running feature branch (quite a bit behind master)
Detached head (taken from develop a long time ago and not updated for a long time)
After fix
Release branch:
Develop (a couple of weeks development ahead of master)
master
Long-running feature branch (quite a bit behind master)
Detached head (taken from develop a long time ago and not updated for a long time)
The text was updated successfully, but these errors were encountered: