git/run-command.c, branch v2.0.2

commit: fix patch hunk editing with "commit -p -m"

2014-03-18T18:25:12Z

Don't change git environment: move the GIT_EDITOR=":" override to the hook command subprocess, like it's already done for GIT_INDEX_FILE. Signed-off-by: Benoit Pierre Signed-off-by: Junio C Hamano

run-command: trivial style fixes

2013-10-31T20:48:26Z

Signed-off-by: Felipe Contreras Signed-off-by: Junio C Hamano

Merge branch 'tr/fd-gotcha-fixes'

2013-07-22T18:23:13Z

Two places we did not check return value (expected to be a file descriptor) correctly. * tr/fd-gotcha-fixes: run-command: dup_devnull(): guard against syscalls failing git_mkstemps: correctly test return value of open()

run-command: dup_devnull(): guard against syscalls failing

2013-07-12T17:30:09Z

dup_devnull() did not check the return values of open() and dup2(). Fix this omission. Signed-off-by: Thomas Rast Signed-off-by: Junio C Hamano

mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE

2013-05-08T19:14:35Z

Throughout git, it is assumed that the WIN32 preprocessor symbol is defined on native Windows setups (mingw and msvc) and not on Cygwin. On Cygwin, most of the time git can pretend this is just another Unix machine, and Windows-specific magic is generally counterproductive. Unfortunately Cygwin *does* define the WIN32 symbol in some headers. Best to rely on a new git-specific symbol GIT_WINDOWS_NATIVE instead, defined as follows: #if defined(WIN32) && !defined(__CYGWIN__) # define GIT_WINDOWS_NATIVE #endif After this change, it should be possible to drop the CYGWIN_V15_WIN32API setting without any negative effect. [rj: %s/WINDOWS_NATIVE/GIT_WINDOWS_NATIVE/g ] Signed-off-by: Jonathan Nieder Signed-off-by: Ramsay Jones Signed-off-by: Junio C Hamano

Merge branch 'jk/a-thread-only-dies-once'

2013-04-19T20:45:05Z

A regression fix for the logic to detect die() handler triggering itself recursively. * jk/a-thread-only-dies-once: run-command: use thread-aware die_is_recursing routine usage: allow pluggable die-recursion checks

run-command: use thread-aware die_is_recursing routine

2013-04-16T22:02:48Z

If we die from an async thread, we do not actually exit the program, but just kill the thread. This confuses the static counter in usage.c's default die_is_recursing function; it updates the counter once for the thread death, and then when the main program calls die() itself, it erroneously thinks we are recursing. The end result is that we print "recursion detected in die handler" instead of the real error in such a case (the easiest way to trigger this is having a remote connection hang up while running a sideband demultiplexer). This patch solves it by using a per-thread counter when the async_die function is installed; we detect recursion in each thread (including the main one), but they do not step on each other's toes. Other threaded code does not need to worry about this, as they do not install specialized die handlers; they just let a die() from a sub-thread take down the whole program. Since we are overriding the default recursion-check function, there is an interesting corner case that is not a problem, but bears some explanation. Imagine the main thread calls die(), and then in the die_routine starts an async call. We will switch to using thread-local storage, which starts at 0, for the main thread's counter, even though the original counter was actually at 1. That's OK, though, for two reasons: 1. It would miss only the first level of recursion, and would still find recursive failures inside the async helper. 2. We do not currently and are not likely to start doing anything as heavyweight as starting an async routine from within a die routine or helper function. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

run-command: always set failed_errno in start_command

2013-03-21T21:06:48Z

When we fail to fork, we set the failed_errno variable to the value of errno so it is not clobbered by later syscalls. However, we do so in a conditional, and it is hard to see later under what conditions the variable has a valid value. Instead of setting it only when fork fails, let's just always set it after forking. This is more obvious for human readers (as we are no longer setting it as a side effect of a strerror call), and it is more obvious to gcc, which no longer generates a spurious -Wuninitialized warning. It also happens to match what the WIN32 half of the #ifdef does. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'sb/run-command-fd-error-reporting'

2013-02-07T22:41:42Z

* sb/run-command-fd-error-reporting: run-command: be more informative about what failed

run-command: be more informative about what failed

2013-02-01T22:11:50Z

While debugging an error with verify_signed_buffer() the error messages from run-command weren't very useful: error: cannot create pipe for gpg: Too many open files error: could not run gpg. because they didn't indicate *which* pipe couldn't be created. Print which pipe failed to be created in the error message so we can more easily debug similar problems in the future. For example, the above error now prints: error: cannot create standard error pipe for gpg: Too many open files error: could not run gpg. Signed-off-by: Stephen Boyd Signed-off-by: Junio C Hamano