Ben Walton wrote: > The issue really comes down to the fact the current code allows a > user's environment at runtime to negatively affect the ability to run > commands that would otherwise be fine. [...] > The way that SANE_TOOL_PATH is injected into PATH for shell scripts > only sees it given priority over /bin and /usr/bin (and things > following them). If this were mimicked for consistency in the > non-script parts of git, users would still be able to have paths with > 'insane' tools given precedence. Oh, that's what you meant. Git could unconditionally override or prefix the PATH with some value determined at build time, but we deliberately gave users more control than that. git-rebase.sh et al make use of various tools from the usual Unix toolset, expecting to find them on the PATH. If the user sets the PATH to point to the Plan 9 tools, say, then these scripts will break. Is that a problem? More importantly: is it the same problem your patch fixes? If "yes", then that is problematic. If the SANE_TOOL_PATH facility is broken, we should be fixing or eliminating it, not piling workarounds on top. If we want to say 'sh' is special, we should mean it. [My personal answers are "no, give them rope" and "no, they are different problems", so I'm not too worried. ;-)] Thanks for some food for thought. Jonathan -- 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