{"thread":{"id":"2766","subject":"Can GIT_EXEC_PATH behave more like PATH?","startedAt":"2005-12-07T14:12:18Z","lastAt":"2005-12-07T19:21:14Z","messageCount":3,"participants":["Martin Atukunda","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13312","messageId":"20051207141218.GA721@igloo.ds.co.ug","threadId":"2766","inReplyTo":null,"subject":"Can GIT_EXEC_PATH behave more like PATH?","fromName":"Martin Atukunda","fromEmail":"matlads@dsmagic.com","sentAt":"2005-12-07T14:12:18Z","receivedAt":"2005-12-07T14:12:18Z","isPatch":false,"sender":{"key":"matlads@dsmagic.com","avatar":null},"body":"Hi,\n\nI've been wondering if GIT_EXEC_PATH shouldn't be able to behave more\nlike the PATH env. variable?\n\nit would allow for instance something like:\n\nGIT_EXEC_PATH=/git/core:/usr/local/git/potty:/usr/lib/git\n\nand naturally git <command> would do the correct thing given.\n\nif so, definetly post 1.0 stuff.\n\nany ideas?\n\n- Martin -\n\n-- \nDue to a shortage of devoted followers, the production of great leaders has been discontinued.\n"},{"id":"13329","messageId":"7v4q5kra80.fsf@assigned-by-dhcp.cox.net","threadId":"2766","inReplyTo":"20051207141218.GA721@igloo.ds.co.ug","subject":"Re: Can GIT_EXEC_PATH behave more like PATH?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T19:14:07Z","receivedAt":"2005-12-07T19:14:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Atukunda <matlads@dsmagic.com> writes:\n\n> I've been wondering if GIT_EXEC_PATH shouldn't be able to behave more\n> like the PATH env. variable?\n\nI do not think it is useful at all.\n\nI think GIT_EXEC_PATH is useful only in two occasions.  (1) When\nPorcelains want to bypass \"git\" to avoid extra forking, it can\nask where the executables are just once to \"git --exec-path\",\nand export GIT_EXEC_PATH with that single path; (2) When you\nwant to try out a freshly built git without installing, you can\nexport GIT_EXEC_PATH set, again with the single path that is\nwhere the build directory is.  Neither wants a list of\ndirectories.\n\nWhen users use \"git frotz\", the git command internally knows\nwhere the right version of subcommands are stored.  When reason\nyou would want to override that, you would exactly know one\ndirectory with which you want to override it.  You do not want\nGIT_EXEC_PATH=\"/usr/lib/git-1.02:/usr/lib/git\" in such a case,\neither.\n"},{"id":"13330","messageId":"7vzmncpvbp.fsf@assigned-by-dhcp.cox.net","threadId":"2766","inReplyTo":"7v4q5kra80.fsf@assigned-by-dhcp.cox.net","subject":"Re: Can GIT_EXEC_PATH behave more like PATH?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-07T19:21:14Z","receivedAt":"2005-12-07T19:21:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> When users use \"git frotz\", the git command internally knows\n> where the right version of subcommands are stored.  When reason\n> you would want to override that, you would exactly know one\n> directory with which you want to override it.  You do not want\n> GIT_EXEC_PATH=\"/usr/lib/git-1.02:/usr/lib/git\" in such a case,\n> either.\n\nOOPS.  That did not parse so well.  \"... When you would want to\noverride that for whatever reason, you would...\"\n"}]}