Han-Wen Nienhuys <hanwen@xxxxxxxxx> writes: > And how about coding the path of git-sh-setup (in <prefix>/bin/git-sh-setup) > in the shell scripts? This will ensure that the sh-setup is the one > from the right package, but still retain backward compatibility for > scripts. Hardcoding $(bin)/git-sh-setup is a non-starter; it breaks GIT_EXEC_PATH convention to allow users to override it. You would need to make sure the following: - If you are moving git-sh-setup out of the way, I think you would need to do the same for git-parse-remote while you are at it. There might be other scriptlets whose sole purpose is to be sourced via "." (I haven't checked recently). - It should be arranged so that "make test" would test the version from the source tree, even when you have an installed version of git-sh-setup and friends elsewhere on your PATH. - People who build but do not install should be able to continue using git from the build location with appropriate environment settings (look for place that talks about PATH and GIT_EXEC_PATH in INSTALL -- if you need something else, you should document new requirements there). I haven't looked closely, but I suspect your patch might have broken the latter two. Having said that, I still do not see the point of doing this. Was there ever a case that you typed git-sh-setup on the command line by mistake (in which case it might be a valid desire to prevent the mistake from happening again)? Command complettion might offer git-sh-setup when you say "git-<TAB>", which might irritate you --- but these days you can use Shawn's completion and say "git <TAB>" or "git somecommand<TAB>", which is way nicer, and makes it not really an issue either. In other words, I do not know what real problem you are trying to solve. - 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