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

timeout if gitmux takes too long to print the result #35

Closed
c02y opened this issue Aug 21, 2020 · 7 comments · Fixed by #37
Closed

timeout if gitmux takes too long to print the result #35

c02y opened this issue Aug 21, 2020 · 7 comments · Fixed by #37
Labels
improvement New feature or request

Comments

@c02y
Copy link

c02y commented Aug 21, 2020

Expected Behavior

When in some situation, gitmux takes too long to print the result, it should just quit and print nothing like it never existed.

This kind is situation is: I got a repo pulled inside Windows partition, and I'm using Linux as the guest on Virtual Machine, and I share the repo folder to the Linux, trust me, I don't want this, anyway, when I'm in this situation, normal git status will take too long so I tried to avoid using git or tig or anything related to git in this repo inside Linux.

Currently my workaround is using #(timeout 2 ~/.local/bin/gitmux #{pane_current_path}) in my ~/.tmux.conf to quit gitmux after 2 seconds whatever the result is.

Could you please add this timeout feature into gitmux, of cause if you think this is unnecessary, that's OK, I can just use my workaround since this is really a special situation.

And if others got the similar problem using gitmux, and once they see this issue page, they can use my workaround too.

Actual Behavior

the "~/.local/bin/gitmux..." string stuck in tmux status bar until it finished.

Steps to Reproduce the Problem

  1. as I said, you may have to be that specific situation, but this is not the problem gitmux but the git itself or even Windows OS

Specifications

  • OS: Manjaro
  • gitmux version: gitmux -V 0.7.0
  • tmux version: tmux -V 3.1b
  • in case the problem only happens in a specific directory: run gitmux -dbg in that directory
@arl
Copy link
Owner

arl commented Aug 21, 2020

Hey there.
Thank you for a very detailed report, and for the workaround.

I agree that you have a very particular environment, but anyway since gitmux purpose is to run inside tmux, it should have the same requirements regarding user interaction, such as not taking too long to perform its job.

I'm ok to add an option for that, but to let the timeout disabled by default

@arl arl added the improvement New feature or request label Aug 21, 2020
arl added a commit that referenced this issue Sep 1, 2020
`-timeout DUR` simply exist `gitmux` is it still running after DUR
amount of time.
DUR is parsed as a time.Duration with the special exception that 0
means no timeout.
Defaults to 0 = _no timeout_

Closes #35
@arl arl mentioned this issue Sep 1, 2020
@arl arl closed this as completed in #37 Sep 1, 2020
arl added a commit that referenced this issue Sep 1, 2020
`-timeout DUR` simply exist `gitmux` is it still running after DUR
amount of time.
DUR is parsed as a time.Duration with the special exception that 0
means no timeout.
Defaults to 0 = _no timeout_

Closes #35
@arl
Copy link
Owner

arl commented Sep 1, 2020

@c02y hey I just merged #37 in master. gitmux now has a -timeout option as requested.
-timeout takes an argument which is the duration after which gitmux, if it's still running, will exit by itself with no output whatsoever.

Argument to -timeout should be of the form:

  • 2s for 2 seconds
  • 50ms for 50 milliseconds
  • even 1s500ms works for example

Please find the latest binary release at https://github.com/arl/gitmux/releases/latest

@c02y
Copy link
Author

c02y commented Sep 2, 2020

[BUG REPORT]:

When I'm using gitmux -timeout 2s ... in my ~/.tmux.conf, and cd into a git repo, there is a process called "git status --porcelain --branch -z" in the background, every time after I'm on a new shell prompt such as just hit Enter key, there will be the same new process git status --porcelain --branch -z in the background again, and I notice that the PPID of all the old ones of those git status --porcelain --branch -z processes will be 1, the new created process has a normal PPID.

NOTE: there is no such issue when using my timeout 2 gitmux ... in ~/.tmux.conf and this only happens inside those special repos when it prints nothing since it takes too long to response with the new gitmux -timeout.

I noticed this issue because I got the .git/index.lock problem after using the new gitmux, it may not be related to the new gitmux since I already posted the bug(#9) and I cannot reproduce the .git/index.lock issue I guess it it produced by Ctrl-c or some other actions I made earlier.

@arl
Copy link
Owner

arl commented Sep 2, 2020

Oh ok I know what that is. I will fix that very soon.
I forgot to place a timeout on the subprocess.

Not related but you should use -timeout 2s and not just 2, you need to provide the unit.

@arl arl reopened this Sep 2, 2020
@c02y
Copy link
Author

c02y commented Sep 2, 2020

Not related but you should use -timeout 2s and not just 2, you need to provide the unit.

Sorry, it is a typo, it is 2s I'm using, fixed in the previous comment.

@arl arl mentioned this issue Sep 2, 2020
@arl
Copy link
Owner

arl commented Sep 2, 2020

Ok that should be fixed now.
As I told you I didn't think at first about the subprocesses that gitmux starts.
Now the -timeout applies to the subprocesses, rather than gitmux.

FYI: gitmux needs to run various git subprocesses in order to gather the information to place in the status string.
Now, the first subprocess that takes longer than the timeout will be killed, furthermore once one subprocess has been killed, no subsequent git subprocess will even be started, resulting in gitmux early exiting as soon as possible.

@c02y Let me know if that's fixed for you so we can close the issue

@c02y
Copy link
Author

c02y commented Sep 3, 2020

Thanks, it is fixed.

@c02y c02y closed this as completed Sep 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants