Andreas Ericsson <ae@op5.se> writes: > Junio C Hamano wrote: >> My current thinking about this problem is that the handful >> programs that need to run "on the other end" should stay in >> /usr/bin, even after we move most things out of /usr/bin, if >> only to avoid configuration hassles. They are: >> receive-pack, upload-pack >> ssh-fetch, ssh-pull, ssh-push, ssh-upload > > I liked your suggestion of deprecating the /usr/bin use a month or two > before it's effected better. We could then provide symlinks for the > necessary programs that point to their real locations in GIT_EXEC_PATH > and (someday) drop those links when they're no longer needed. Yes, but the problem is when that "someday" comes. Unlike a single machine installation where we can tell "git" to look into somewhere different at the same time we move the subcommands out of /usr/bin, "the other end" can lag behind and sometimes not under control of the end user. I think it's simpler to manage and can be made configuration free if we keep receive-pack and upload-pack in /usr/bin and always call these programs in dash-form (i.e. not "git upload-pack") from the other end. .bash_profile is not read for incoming ssh connections to execute a single command, but many people set their PATH in there, without setting PATH in .bashrc. I personally think that having to set PATH in .bashrc it is actually a bug in what bash does, but that is OT. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Nov 15 08:17:29 2005
This archive was generated by hypermail 2.1.8 : 2005-11-15 08:17:34 EST