On Samstag, 19. Juli 2008, Junio C Hamano wrote: > Sorry, I am not sure if I understand what you are trying to solve. If you > have ../libexec/git-core/ in GIT_EXEC_PATH (or have builtin_exec_path() > use it), then your installation would look like this: > > [[some random place]] > bin/git > libexec/git-core/git-add > libexec/git-core/git-del > libexec/git-core/git-dir > ... > > and if "git" can figure out it is "[[some random place]]/bin/git", > it can find its subcommands from neighbouring directory, that is still > inside the random place the user told the installer to use, can't it? Yes, but... Take as an example 'git pull'. - The first call to git will derive the exec-path $prefix/bin/../libexec/git-core and prepend it to $PATH. - Calls to builtin git commands from inside 'git pull' will then derive the exec-path $prefix/bin/../libexec/git-core/../libexec/git-core, that is $prefix/libexec/libexec/git-core, and prepend it to $PATH as well. That directory does not exist - usually - and it does not hurt. But it feels dirty and potentially dangerous. > > This counteracts the aims of the "dash-less" change on Windows, but > > better this way than having no working git at all. > > I'd agree to the extent that anything is better than having no working > git, but this somewhat feels backwards. It certainly does. I'm hoping that the msysgit crew has an opinion on this. CMD users like me do not care how cluttered $PATH is because there is no command completion that would reveal the 100+ git commands. But msysgit users who are working from a bash may want to have them hidden outside $PATH. Or maybe they do not care. -- Hannes -- 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
