Slow on larger repos
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- git, python
- Domain
- cli, performance
Research direction
No source files or tests are named. Start by profiling git stack restack and git stack list on the reported large and empty repositories, then trace the commands' runtime against commit and branch counts. Done means identifying and correcting the inefficiency so runtime does not scale unnecessarily with repository size.
Written by the indexing model from the issue text.
Description
I'm on a repo with 580 commits in the HEAD tree (and 960 branches in git branch -av), and it roughly takes 17 seconds to run git stack restack, and 34 seconds to run git stack list.
On an empty repo, this seems to be much faster. On both cases, the stack height is 3. I believe there's an inefficiency somewhere that linearly increases the run-time with commit count.
- Dominant language
- Python
- Stars
- 17
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stevearc/gitstack
-
Difficulty 3/5 1-2 days Newbie friendliness 35/100
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 42/100
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
All issues in stevearc/gitstack
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100