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

run-command.c: print new cwd in trace_run_command()

2018-01-19T18:49:20Z

If a command sets a new env variable GIT_DIR=.git, we need more context to know where that '.git' is related to. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

run-command.c: print env vars in trace_run_command()

2018-01-19T18:49:20Z

Occasionally submodule code could execute new commands with GIT_DIR set to some submodule. GIT_TRACE prints just the command line which makes it hard to tell that it's not really executed on this repository. Print the env delta (compared to parent environment) in this case. Helped-by: Junio C Hamano Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

run-command.c: print program 'git' when tracing git_cmd mode

2018-01-19T18:49:20Z

We normally print full command line, including the program and its argument. When git_cmd is set, we have a special code path to run the right "git" program and child_process.argv[0] will not contain the program name anymore. As a result, we print just the command arguments. I thought it was a regression when the code was refactored and git_cmd added, but apparently it's not. git_cmd mode was introduced before tracing was added in 8852f5d704 (run_command(): respect GIT_TRACE - 2008-07-07) so it's more like an oversight in 8852f5d704. Fix it, print the program name "git" in git_cmd mode. It's nice to have now. But it will be more important later when we start to print env variables too, in shell syntax. The lack of a program name would look confusing then. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

run-command.c: introduce trace_run_command()

2018-01-19T18:49:20Z

This is the same as the old code that uses trace_argv_printf() in run-command.c. This function will be improved in later patches to print more information from struct child_process. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano

run-command: add hint when a hook is ignored

2017-10-10T04:21:46Z

When an hook is present but the file is not set as executable then git will ignore the hook. For now this is silent which can be confusing. This commit adds this warning to improve the situation: hint: The 'pre-commit' hook was ignored because it's not set as executable. hint: You can disable this warning with `git config advice.ignoredHook false` To allow the old use-case of enabling/disabling hooks via the executable flag a new setting is introduced: advice.ignoredHook. Signed-off-by: Damien Marié Signed-off-by: Junio C Hamano

run-command: use ALLOC_ARRAY

2017-10-02T23:42:57Z

Use the macro ALLOC_ARRAY to allocate an array. This is shorter and easier, as it automatically infers the size of elements. Patch generated with Coccinelle and contrib/coccinelle/array.cocci. Signeg-off-by: Rene Scharfe Signed-off-by: Junio C Hamano

Merge branch 'js/run-process-parallel-api-fix' into maint

2017-08-23T21:33:49Z

API fix. * js/run-process-parallel-api-fix: run_processes_parallel: change confusing task_cb convention

run_processes_parallel: change confusing task_cb convention

2017-07-21T18:58:46Z

By declaring the task_cb parameter of type `void **`, the signature of the get_next_task method suggests that the "task-specific cookie" can be defined in that method, and the signatures of the start_failure and of the task_finished methods declare that parameter of type `void *`, suggesting that those methods are mere users of said cookie. That convention makes a total lot of sense, because the tasks are pretty much dead when one of the latter two methods is called: there would be little use to reset that cookie at that point because nobody would be able to see the change afterwards. However, this is not what the code actually does. For all three methods, it passes the *address* of pp->children[i].data. As reasoned above, this behavior makes no sense. So let's change the implementation to adhere to the convention suggested by the signatures. Signed-off-by: Johannes Schindelin Acked-by: Stefan Beller Signed-off-by: Junio C Hamano

run-command: restrict PATH search to executable files

2017-04-26T06:17:36Z

In some situations run-command will incorrectly try (and fail) to execute a directory instead of an executable file. This was observed by having a directory called "ssh" in $PATH before the real ssh and trying to use ssh protoccol, reslting in the following: $ git ls-remote ssh://url fatal: cannot exec 'ssh': Permission denied It ends up being worse and run-command will even try to execute a non-executable file if it preceeds the executable version of a file on the PATH. For example, if PATH=~/bin1:~/bin2:~/bin3 and there exists a directory 'git-hello' in 'bin1', a non-executable file 'git-hello' in bin2 and an executable file 'git-hello' (which prints "Hello World!") in bin3 the following will occur: $ git hello fatal: cannot exec 'git-hello': Permission denied This is due to only checking 'access()' when locating an executable in PATH, which doesn't distinguish between files and directories. Instead use 'is_executable()' which check that the path is to a regular, executable file. Now run-command won't try to execute the directory or non-executable file 'git-hello': $ git hello Hello World! which matches what execvp(3) would have done when asked to execute git-hello with such a $PATH. Reported-by: Brian Hatfield Signed-off-by: Brandon Williams Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano

run-command: expose is_executable function

2017-04-26T01:45:29Z

Move the logic for 'is_executable()' from help.c to run_command.c and expose it so that callers from outside help.c can access the function. This is to enable run-command to be able to query if a file is executable in a future patch. Signed-off-by: Brandon Williams Reviewed-by: Jonathan Nieder Signed-off-by: Junio C Hamano