Skip to content
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

Improve the commit history browsing performances #45

Open
flelli opened this issue Mar 7, 2021 · 4 comments
Open

Improve the commit history browsing performances #45

flelli opened this issue Mar 7, 2021 · 4 comments
Assignees
Labels
provides:enhancement The issue provides one or more generic enhancements type::task Short term actionable activity.

Comments

@flelli
Copy link
Collaborator

flelli commented Mar 7, 2021

Method JGitRepository.walkHistory() is slow and thatàs probably due to the retrieval of all tags for each commit.
Its performances must be improved.

@flelli flelli added state::backlog The issue is accepted in the backlog and waiting to be planned or worked on provides:enhancement The issue provides one or more generic enhancements type::task Short term actionable activity. labels Mar 7, 2021
@flelli flelli self-assigned this May 11, 2021
@flelli flelli removed the state::backlog The issue is accepted in the backlog and waiting to be planned or worked on label Aug 21, 2023
@sschuberth
Copy link

I'm also suffering from nyx --preset=simple infer to be insanely slow (when being mean and trying on a repository without any version tags).

But I'm wondering whether really JGitRepository.walkHistory() is the culprit, as I though the relevant code is not

repository().walkHistory(null, null, c -> {

but

(*c.Repository()).WalkHistory(nil, nil, func(cc gitent.Commit) bool {

for the CLI tool.

Anyway, I believe the problem could be rather the algorithm. Instead of walking all history (as it seems), wouldn't it make more sense to determine only the latest tag (if any) on the current branch, any only from there walk up the history to determine the version increment based on conventional commits?

@flelli
Copy link
Collaborator Author

flelli commented Aug 24, 2023

Hi @sschuberth ,

it's very likely, as you say, the issue is in the algorithm and ideas are welcome, considering that:

  • we need to start to walk the history from the latest commit, not by the latest tag, because last commits (up to the latest tags) are exactly what we need to compute version increments
  • the first parent criteria is required to comply with the history of significant commits and prevents us from using commits selected by any criteria other than sequential (i.e. browsing by tags would miss a bunch of significant commits and also potentially drive the browsing out of the range of commits visible starting from HEAD)

When I first noticed this issue I only had the Java implementation, no Go yet, so Java is affected for sure. Nonetheless, as you pointed out, the issue is the algorithm, regardless the language.

@sschuberth
Copy link

For testing, I was trying Git.SemVersioning.Gradle on the same project, which was much faster. Maybe we could borrow some ideas from https://github.com/jmongard/Git.SemVersioning.Gradle/blob/master/src/main/kotlin/git/semver/plugin/semver/VersionFinder.kt?

@sschuberth
Copy link

And for the Go version, maybe compare with https://github.com/PSanetra/git-semver.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
provides:enhancement The issue provides one or more generic enhancements type::task Short term actionable activity.
Projects
None yet
Development

No branches or pull requests

2 participants