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.

Sign up for GitHub

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

Jump to bottom

is_rev_in_remote timesout on large repos #34

Closed
ryaminal opened this issue Oct 28, 2021 · 2 comments · Fixed by #37
Closed

is_rev_in_remote timesout on large repos #34

ryaminal opened this issue Oct 28, 2021 · 2 comments · Fixed by #37
Assignees
@ruifm
Labels
enhancement New feature or request

Comments

@ryaminal
Copy link

Is your feature request related to a problem? Please describe.
require'gitlinker'.get_buf_range_url('n') timesout after 5 seconds

Describe the solution you'd like
A quick-ish short term solution would be to have an option to easily change the timeouts. This isn't the "desired" solution but it seems like it's the most likely "solution" to the problem.

Describe alternatives you've considered
Alternative solutions would be to either have an option or something that removes the need to make this call. Or, if the call is necessary if there is a way to cache the response. I wish my git skills/knowledge was greater but it isn't so I don't really know what this information is being used for.

Additional context
Currently, I am working in a fairly large monorepo.
A git branch --remotes | wc -l shows roughly 2525 remote branches.
I'm assuming that if I clean up remote branches, that this will be a non-problem, but I don't know how realistic that is to do.
So, the problem is that the default plenary job timeout appears to be 5s. The command from is_rev_in_remote(git branch --remotes --contains HEAD) takes almost 30 seconds to complete in the monorepo mentioned above. The culprit is the --contains HEAD portion of the command. I mean, the real problem is this gigantic monorepo with so many "dangling" branches.
@ryaminal ryaminal added the enhancement New feature or request label Oct 28, 2021
@ruifm
Copy link
Owner

ruifm commented Oct 29, 2021

I see how this can be an issue.

IMO, better than configurable timeouts would be default "sane" timeouts for every git call, exposing that as option just increases configuration bloat. If a git call times out, the plugin should give a nice error message.

Another mitigation I can do it to prioritize @{u} (the remote tracking branch) more than HEAD, then I do not need to call is_rev_in_remote if @{u} exists (i.e. you have a remote tracking branch set up for your current branch). That would allow you to use gitlinker without limitations as along as your branch had a remote tracking branch.

I will try to put a PR today.

ruifm added a commit that referenced this issue Nov 29, 2021
@ruifm
perf: try remote branch first
59ee024 
Fixes #34
@ruifm ruifm mentioned this issue Nov 29, 2021
Merged
@ruifm
Copy link
Owner

ruifm commented Nov 29, 2021

Sorry for the delay, I think #37 should address the performance impact of repos with a lot of blobs since now the remote tracking branch is checked first.

You should only have this issue if no remote tracking branch is set for the current branch, which forces a search in the configured remote, commit by commit.

Let me know if the issue persists.

@ruifm ruifm closed this as completed in #37 Nov 29, 2021
stevanmilic pushed a commit to stevanmilic/gitlinker.nvim that referenced this issue Nov 12, 2023
@linrongbin16
feat: add contribution (ruifm#34)
135d990
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ruifm ruifm

Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Try remote branch first ruifm/gitlinker.nvim
2 participants
@ryaminal @ruifm