Ben Walton <bwalton@xxxxxxxxxxxxxxxxxx> writes: > Possible fixes for this issue are: > ... > 2. The git wrapper could prepend SANE_TOOL_PATH to PATH for > consistency with builtin commands. > > 3. The run_command.c:prepare_shell_command() could use the same > SHELL_PATH that is in the #! line of all all scripts. > ... > Option 2 is voided by the same example that turned up this issue. > SANE_TOOL_PATH might also include 'insane' tools. > > Option 3 is the best choice at this time. This line of reasoning makes me feel uneasy. The approach may allow a directory that has "insane" tools in it to be on the SANE_TOOL_PATH for *this* particular codepath, but at the same time, it encourages people to build Git with such a broken SANE_TOOL_PATH. Aren't you exposing your users to potential breakage in other parts of the system, caused by broken tools on SANE_TOOL_PATH that is not shell, by doing so? Worse yet, there is no escape hatch similar to SHELL_PATH for such tools. Will queue on 'pu' for now, but I am not convinced. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html