Detach Git Bash #15
Detach Git Bash #15
Conversation
|
For the record: I will not merge this unless somebody who has the problem reported it. It's a bit unfair that most of the work has been done by somebody who does not even use Windows Explorer on a regular basis, while those who do munched their popcorn on their couch. |
|
Life's not fair. Is this addressed or not? What will it take to merge it with the next release(s)? |
Git-Cheetah redirects and reads stdout / stderr of forked commands only if it needs to. Otherwise this output simply goes to stdout / stderr of the calling file manager process. This is OK for GUI-based file managers (e.g. Windows Explorer), as there is no console. For text-based file managers (e.g. Far Manager) this is a problem, as such unwanted console output messes up the UI. Redirect stdout / stderr of forked commands to /dev/null if Git-Cheetah doesn't need it. Signed-off-by: Karsten Blees <blees@dcon.de>
|
@mwpowellhtx as I said: this will not be merged unless somebody whose problem this actually is has tested this. It could be you. Or not. |
|
Sounds like other contributors already have somewhat of a handle on it. No sense too many chefs being in the kitchen to take care of it. |
When called from the Windows Explorer, we must not wait for the stdout/stderr of Git Bash. A recent change made for FarManager makes Git Cheetah capture stderr/stdout even when we are not interested in it, to avoid cluttering FarManager's precious console. Due to this workaround, Git Bash makes the Explorer -- Git Cheetah's primary intended consumer -- hang. Since Git Bash does not output anything to the calling console, let's just force the detached mode by avoiding the FarManager workaround *just* for Git Bash. Thanks to John Stevenson for catching a bug in an earlier version of this commit. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
Well, @mwpowellhtx, if you ever wanted to make sure that this fix addresses the problem you reported yourself, you still have the chance. You might like the reputation you get by at least testing the fix on your side. At least I myself would prefer to have that kind of reputation. |
Detach Git Bash Tested by @johnstevenson.
|
I tried to compile the fixes and test, but I honestly have no idea how to get it to. I have however, verified this problem on two different windows 7 computers and tested it thoroughly for variations or workarounds. Also, this occurs for ALL context items, git gui, gitk, etc.Not just gitbash. Until you manually close the item you opened, the explorer window is frozen. Only items that end their own process do not hang the explorer window, but they do hang it up until they have completed. |
|
@dammitcoetzee Git v1.9.1 is out for almost two weeks now, so we will soon release a new Git for Windows version. Hopefully. Unfortunately, my Git time budget is dominated by a different problem now. In the meantime, you can compile Git-Cheetah by following the instructions in the Wiki. |
When called from the Windows Explorer, we must not wait for the
stdout/stderr of Git Bash.
A recent change made for FarManager makes Git Cheetah capture
stderr/stdout even when we are not interested in it, to avoid cluttering
FarManager's precious console. Due to this workaround, Git Bash makes the
Explorer -- Git Cheetah's primary intended consumer -- hang.
Since Git Bash does not output anything to the calling console, let's just
force the detached mode by avoiding the FarManager workaround just for
Git Bash.
Signed-off-by: Johannes Schindelin johannes.schindelin@gmx.de