Subject: Re: [bug] git closes cmd.exe - msg#00118

List: version-control.msysgit

Mail Archive Navigation:
by Date: Prev Next Date Index by Thread: Prev Next Thread Index

Hi Stephan.

Receipe
1. Open Windows command-line cmd.exe.
2. git status

Symptoms
The command-line is immediately closed.

Expected behaviour
Command-line is not closed after git commands.

Proposed change
In git.cmd replacing the line

exit %ErrorLevel%

by

exit /b %ErrorLevel%

seems to solve the problem.

Just a word of warning related to this...

We ran into a similar issue in one of our non-git related 'batch' files where we actually had to leave the 'exit %ErrorLevel%' construct. This was needed because the script got called using the 'cmd /c ...' command and its return value would not propagate through the intermediate cmd shell. As a workaround we now have two scripts - the main worker one doing the 'exit %ErrorLevel%' that may be called using the 'cmd /c ...' command and a wrapper one doing the 'exit /b %ErrorLevel%' that calls the worker using the 'cmd /c ...' construct that may be called directly from the command line.

Not sure if this use-case applies to git.cmd, but I hope it helps someone...

Best regards,
Jurko GospodnetiÄ

Thread at a glance:

Previous Message by Date:

[bug] git closes cmd.exe

Receipe 1. Open Windows command-line cmd.exe. 2. git status Symptoms The command-line is immediately closed. Expected behaviour Command-line is not closed after git commands. Proposed change In git.cmd replacing the line exit %ErrorLevel% by exit /b %ErrorLevel% seems to solve the problem. Best regards, Stephan Hennig

Next Message by Date:

Re: [msysGit] Re: [Tortoisehg-discuss] Bazzar stratgy regarding shell extension

Peer Sommerlund wrote: On 19/04/2008, *Stefan Küng* <tortoisesvn@xxxxxxxxx <mailto:tortoisesvn@xxxxxxxxx>> wrote: Peer Sommerlund wrote: I'm crosposting this to all tortoises I know of - the Windows Overlay problem is relevant to all. (//git-cheetah //is a tortoise in disguise) > [copy of http://bazaar-vcs.org/bzr/bzr.dev/doc/developers/tortoise-strategy.txt] [Peer] I think that the TortoiseOverlay component could evolve into a separate project, were some of the features mentioned in the bzr tortoise strategy (space-efficient DLL architecture, separate tortoise-processes) would fit nicely, and benefit all tortoises. [Stefan] I'm not sure what exactly you want to improve here. After I have thought some more about it I realise that it is probably NOT a good idea to try to build a generalized stub. The analysis by Mark Hammond indicates that script-based tortoises (TBZR and THG) will get version conflicts and bloated memory usage. The proposed solution is a small C++ client that calls a server application (in Python). As you have explained, TSVN has a similar structure, but for different reasons. The client TortoiseStub allows you to select which of three modes to use (cache/shell/none), and the server TortoiseCache can crawl the file system to give faster display of overlay icons. The TortoiseStub is not to select which mode to use but only to prevent apps other than explorer.exe from loading the extension dlls. The mode 'switch' is done in the TortoiseSVN dll. It makes sense for TBZR and THG to share code for the tortoise stub (the client), but why should any other tortoises want a common code base? The consequence would be (1) wider audience means that tortoisestub would be tested more. (2) complexity increases by generalizing TSVN stub instead of forking it. The first is void for TSVN as they have a large audience, and the code has been tested for a while. Refactoring the code would only destabilize it. The latter is an argument against common code. Conclusion: TBZR and THG should do their own stub, probably by forking TSVN code. I'm still not quite sure what code exactly you want to share between the Tortoise clients. Calling the status process would definitely not work, since it would not only be the status that's cached (at least TSVN caches a lot more info than just the status - in fact it caches all information that is available from the working copy). So if you would want to share that code, you'd have to either get a list of information that all Tortoise clients could cache - which means a *lot* of overhead since I doubt that the different versioning systems have a lot of that information in common. Stefan -- ___ oo // \\ "De Chelonian Mobile" (_,\/ \_/ \ TortoiseSVN \ \_/_\_/> The coolest Interface to (Sub)Version Control /_/ \_\ http://tortoisesvn.net signature.asc Description: OpenPGP digital signature

Previous Message by Thread:

Next Message by Thread:

Re: [bug] git closes cmd.exe

On Apr 21, 2008, at 6:01 PM, Stephan Hennig wrote: Receipe 1. Open Windows command-line cmd.exe. 2. git status Symptoms The command-line is immediately closed. Expected behaviour Command-line is not closed after git commands. Proposed change In git.cmd replacing the line exit %ErrorLevel% by exit /b %ErrorLevel% seems to solve the problem. The solution you propose is already on branch devel (b8250c09c) and will be included in the next release. Steffen