search

arl / gitmux

:computer: Git in your tmux status bar
MIT License
630 stars 24 forks source link

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

Closed c02y closed 4 years ago

c02y commented 4 years ago

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

arl commented 4 years ago

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 commented 4 years ago

@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:

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

c02y commented 4 years ago

[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(https://github.com/arl/gitmux/issues/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 commented 4 years ago

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.

c02y commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Thanks, it is fixed.