pr-1468/newren/fix-name-rev-v1
tagged this
21 Jan 04:28
From: Elijah Newren <newren@gmail.com> Commit 7550424804 ("name-rev: include taggerdate in considering the best name", 2016-04-22) introduced the idea of using taggerdate in the criteria for selecting the best name. At the time, a certain commit in linux.git -- namely, aed06b9cfcab -- was being named by name-rev as v4.6-rc1~9^2~792 which, while correct, felt very suboptimal. Some investigation found that tweaking the MERGE_TRAVERSAL_WEIGHT to lower it could give alternate answers such as v3.13-rc7~9^2~14^2~42 or v3.13~5^2~4^2~2^2~1^2~42 A manual solution involving looking at tagger dates came up with v3.13-rc1~65^2^2~42 which was then implemented in name-rev. It turns out that this taggerdate heuristic isn't needed due to a subsequent change to fix the naming logic in 3656f84278 ("name-rev: prefer shorter names over following merges", 2021-12-04). Simply removing the taggerdate heuristic from the calculation nowadays still causes us to get the optimal answer on that particular commit of interest in linux.git, namely: v3.13-rc1~65^2^2~42 Further, the taggerdate heuristic is causing bugs of its own. I was pointed to a case in a private repository where name-rev reports a name of the form v2022.10.02~86 when users expected to see one of the form v2022.10.01~2 (I've modified the names and numbers a bit from the real testcase.) As you can probably guess, v2022.10.01 was created after v2022.10.02 (by a few hours), even though it pointed to an older commit. While the condition is unusual even in the repository in question, it is not the only problematic set of tags in that repository. The taggerdate logic was a workaround that is no longer needed, and is now causing suboptimal results in other cases. As such, remove the taggerdate in the comparison. However, note that "taggerdate" is actually also used to store commit dates since ef1e74065c ("name-rev: favor describing with tags and use committer date to tiebreak", 2017-03-29), where it is used as a fallback tiebreaker when distances are equal. We do not want to remove that fallback tiebreaker, we are only removing the use of actual taggerdates as a primary criteria overridding effective distance calculations. Signed-off-by: Elijah Newren <newren@gmail.com> Submitted-As: https://lore.kernel.org/git/pull.1468.git.1674275336636.gitgitgadget@gmail.com
Assets 2
-
2023-01-21T04:28:56Z -
2023-01-21T04:28:56Z - Loading