{"thread":{"id":"3648","subject":"[PATCH] Invoke git-repo-config directly.","startedAt":"2006-03-14T21:10:22Z","lastAt":"2006-03-17T10:51:33Z","messageCount":27,"participants":["Qingning Huo","Johannes Schindelin","Linus Torvalds","Junio C Hamano","Andreas Ericsson","Mark Wooding","Timo Hirvonen","Jon Loeliger"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"17551","messageId":"20060314211022.GA12498@localhost.localdomain","threadId":"3648","inReplyTo":null,"subject":"[PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.co.uk","sentAt":"2006-03-14T21:10:22Z","receivedAt":"2006-03-14T21:10:22Z","isPatch":true,"sender":{"key":"qhuo@mayhq.co.uk","avatar":null},"body":"The system have GNU git installed at /usr/bin/git.  I installed git-core\nto ~/opt/bin.  ~/opt/bin is in my PATH, but is after /usr/bin.  I have\nset alias git=\"$HOME/opt/bin/git\".\n\ngit-push and git-pull behaves strangely, because they call \"git\nrepo-config\", which runs /usr/bin/git.  Using \"git-repo-config\" directly\nfixed the problem.\n\nSigned-off-by: Qingning Huo <qhuo@mayhq.co.uk>\n\n---\n\n git-pull.sh     |    4 ++--\n git-sh-setup.sh |    2 +-\n 2 files changed, 3 insertions(+), 3 deletions(-)\n\na0194fff002cb12ac58b202201d387f8ea55b225\ndiff --git a/git-pull.sh b/git-pull.sh\nindex 6caf1aa..e32e2b0 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -70,7 +70,7 @@ case \"$merge_head\" in\n \texit 0\n \t;;\n ?*' '?*)\n-\tvar=`git repo-config --get pull.octopus`\n+\tvar=`git-repo-config --get pull.octopus`\n \tif test '' = \"$var\"\n \tthen\n \t\tstrategy_default_args='-s octopus'\n@@ -79,7 +79,7 @@ case \"$merge_head\" in\n \tfi\n \t;;\n *)\n-\tvar=`git repo-config --get pull.twohead`\n+\tvar=`git-repo-config --get pull.twohead`\n \tif test '' = \"$var\"\n \tthen\n \t\tstrategy_default_args='-s recursive'\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex 025ef2d..12f5ede 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -41,7 +41,7 @@ then\n \t: ${GIT_OBJECT_DIRECTORY=\"$GIT_DIR/objects\"}\n \n \t# Make sure we are in a valid repository of a vintage we understand.\n-\tGIT_DIR=\"$GIT_DIR\" git repo-config --get core.nosuch >/dev/null\n+\tGIT_DIR=\"$GIT_DIR\" git-repo-config --get core.nosuch >/dev/null\n \tif test $? = 128\n \tthen\n \t    exit\n-- \n1.2.4.ga019-dirty\n"},{"id":"17553","messageId":"Pine.LNX.4.63.0603142219040.23646@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3648","inReplyTo":"20060314211022.GA12498@localhost.localdomain","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-14T21:20:53Z","receivedAt":"2006-03-14T21:20:53Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Mar 2006, Qingning Huo wrote:\n\n> -\tvar=`git repo-config --get pull.octopus`\n> +\tvar=`git-repo-config --get pull.octopus`\n\nThis is unlikely to be applied; there are plans to have a \"libexec\" path \nin which all git executables are stored, and just the \"git\" wrapper in the \npath. Your patch would break git in those setups.\n\nCiao,\nDscho\n\nP.S.: BTW there are quite a few discussions of this in the mailing list \narchives...\n"},{"id":"17554","messageId":"20060314213014.GA12862@localhost.localdomain","threadId":"3648","inReplyTo":"Pine.LNX.4.63.0603142219040.23646@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.co.uk","sentAt":"2006-03-14T21:30:14Z","receivedAt":"2006-03-14T21:30:14Z","isPatch":true,"sender":{"key":"qhuo@mayhq.co.uk","avatar":null},"body":"On Tue, Mar 14, 2006 at 10:20:53PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 14 Mar 2006, Qingning Huo wrote:\n> \n> > -\tvar=`git repo-config --get pull.octopus`\n> > +\tvar=`git-repo-config --get pull.octopus`\n> \n> This is unlikely to be applied; there are plans to have a \"libexec\" path \n> in which all git executables are stored, and just the \"git\" wrapper in the \n> path. Your patch would break git in those setups.\n> \n\nI do not mind whether this patch is applied.  What I want is git calls\nits helper programs, instead of any random git program in my PATH.  If\ngit-programs are installed to libexec path, how about calling them\nwith absolute path?\n\nRegards,\nQingning\n"},{"id":"17555","messageId":"Pine.LNX.4.64.0603141351470.3618@g5.osdl.org","threadId":"3648","inReplyTo":"20060314211022.GA12498@localhost.localdomain","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-14T21:58:09Z","receivedAt":"2006-03-14T21:58:09Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Mar 2006, Qingning Huo wrote:\n>\n> The system have GNU git installed at /usr/bin/git.  I installed git-core\n> to ~/opt/bin.  ~/opt/bin is in my PATH, but is after /usr/bin.  I have\n> set alias git=\"$HOME/opt/bin/git\".\n\nThis should not be a problem with the modern \"git.c\" wrapper. It \n_should_, if you call it with the full path, automatically prepend that \npath to the PATH when executing sub-commands. \n\nSo if you run git as \"$HOME/opt/bin/git\", the PATH _should_ be \n - first the \"PREFIX/bin\" path as defined by the build\n - second the \"$HOME/opt/bin/\" path as defined by the fact that you ran \n   git from that path\n - finally the normal $PATH.\n\nTo check this out, do this:\n\n\tln -s /usr/bin/printenv ~/opt/bin/git-printenv\n\tgit printenv\n\nand you should see the proper PATH that git ends up using internally that \nway.\n\nSo your problem seems to be that you do \"git-pull\", when you really should \ndo \"git pull\" (where that wrapper will set up PATH for you). Since you \ndon't use the wrapper, the scripts end up doing the wrong thing.\n\n\t\tLinus\n"},{"id":"17556","messageId":"20060314224027.GB14733@localhost.localdomain","threadId":"3648","inReplyTo":"Pine.LNX.4.64.0603141351470.3618@g5.osdl.org","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.co.uk","sentAt":"2006-03-14T22:40:27Z","receivedAt":"2006-03-14T22:40:27Z","isPatch":true,"sender":{"key":"qhuo@mayhq.co.uk","avatar":null},"body":"On Tue, Mar 14, 2006 at 01:58:09PM -0800, Linus Torvalds wrote:\n> \n> \n> On Tue, 14 Mar 2006, Qingning Huo wrote:\n> >\n> > The system have GNU git installed at /usr/bin/git.  I installed git-core\n> > to ~/opt/bin.  ~/opt/bin is in my PATH, but is after /usr/bin.  I have\n> > set alias git=\"$HOME/opt/bin/git\".\n> \n> This should not be a problem with the modern \"git.c\" wrapper. It \n> _should_, if you call it with the full path, automatically prepend that \n> path to the PATH when executing sub-commands. \n> \n> So if you run git as \"$HOME/opt/bin/git\", the PATH _should_ be \n>  - first the \"PREFIX/bin\" path as defined by the build\n>  - second the \"$HOME/opt/bin/\" path as defined by the fact that you ran \n>    git from that path\n>  - finally the normal $PATH.\n> \n> To check this out, do this:\n> \n> \tln -s /usr/bin/printenv ~/opt/bin/git-printenv\n> \tgit printenv\n> \n> and you should see the proper PATH that git ends up using internally that \n> way.\n> \n> So your problem seems to be that you do \"git-pull\", when you really should \n> do \"git pull\" (where that wrapper will set up PATH for you). Since you \n> don't use the wrapper, the scripts end up doing the wrong thing.\n> \n\nThanks for your detailed explanation.  Yes, \"git push\" and \"git pull\"\nboth work fine out of the box.  That is the good thing.  But,\n\n$ grep git git-pull.sh\n\n. git-sh-setup\norig_head=$(git-rev-parse --verify HEAD) || die \"Pulling into a black hole?\"\ngit-fetch --update-head-ok \"$@\" || exit 1\ncurr_head=$(git-rev-parse --verify HEAD)\n        git-read-tree -u -m \"$orig_head\" \"$curr_head\" ||\n        var=`git repo-config --get pull.octopus`\n        var=`git repo-config --get pull.twohead`\nmerge_name=$(git-fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\")\ngit-merge $no_summary $no_commit $strategy_args \"$merge_name\" HEAD $merge_head\n\nWe have \"git-read-tree\" and \"git repo-config\" at the same time.  Are\nthere any rules saying which form should be preferred?  How about pick\none form and stick to it?\n\nIf we uniformly call git helper programs/scripts with \"git helper\"\nstyle, would git(1) append two paths to PATH everytime it is being\ninvoked?  For example, \"git pull\" -> \"git repo-config\" would prepend\n~/opt/bin four times to PATH.  This wouldn't be very effecient.\n\nRegards,\nQingning\n"},{"id":"17557","messageId":"Pine.LNX.4.64.0603141506130.3618@g5.osdl.org","threadId":"3648","inReplyTo":"20060314224027.GB14733@localhost.localdomain","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-14T23:07:39Z","receivedAt":"2006-03-14T23:07:39Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Mar 2006, Qingning Huo wrote:\n> \n> Thanks for your detailed explanation.  Yes, \"git push\" and \"git pull\"\n> both work fine out of the box.  That is the good thing.  But,\n> \n> $ grep git git-pull.sh\n> \n> . git-sh-setup\n> orig_head=$(git-rev-parse --verify HEAD) || die \"Pulling into a black hole?\"\n> git-fetch --update-head-ok \"$@\" || exit 1\n> curr_head=$(git-rev-parse --verify HEAD)\n>         git-read-tree -u -m \"$orig_head\" \"$curr_head\" ||\n>         var=`git repo-config --get pull.octopus`\n>         var=`git repo-config --get pull.twohead`\n> merge_name=$(git-fmt-merge-msg <\"$GIT_DIR/FETCH_HEAD\")\n> git-merge $no_summary $no_commit $strategy_args \"$merge_name\" HEAD $merge_head\n> \n> We have \"git-read-tree\" and \"git repo-config\" at the same time.  Are\n> there any rules saying which form should be preferred?  How about pick\n> one form and stick to it?\n\nI agree that it is inconsistent as-is. So a patch to make it use the \n\"git-repo-config\" form (the argument being that internally, we use the \nfull names) might be good if just for consistency.\n\n\t\tLinus\n"},{"id":"17569","messageId":"20060315204003.GA6154@localhost.localdomain","threadId":"3648","inReplyTo":"Pine.LNX.4.64.0603141506130.3618@g5.osdl.org","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.co.uk","sentAt":"2006-03-15T20:40:03Z","receivedAt":"2006-03-15T20:40:03Z","isPatch":true,"sender":{"key":"qhuo@mayhq.co.uk","avatar":null},"body":"On Tue, Mar 14, 2006 at 03:07:39PM -0800, Linus Torvalds wrote:\n> On Tue, 14 Mar 2006, Qingning Huo wrote:\n> > We have \"git-read-tree\" and \"git repo-config\" at the same time.  Are\n> > there any rules saying which form should be preferred?  How about pick\n> > one form and stick to it?\n> \n> I agree that it is inconsistent as-is. So a patch to make it use the \n> \"git-repo-config\" form (the argument being that internally, we use the \n> full names) might be good if just for consistency.\n> \n\nCan these two patches be accepted then?  What do others think?\n\nQingning\n"},{"id":"17570","messageId":"7vek13ieap.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"Pine.LNX.4.64.0603141506130.3618@g5.osdl.org","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-15T21:33:18Z","receivedAt":"2006-03-15T21:33:18Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> I agree that it is inconsistent as-is. So a patch to make it use the \n> \"git-repo-config\" form (the argument being that internally, we use the \n> full names) might be good if just for consistency.\n\nIf we do the dash-form for consistency's sake, we should do\nPATH=\"`git --exec-path`:$PATH\" in git-setup-sh when/before we do\nso.  For scripts that do not use git-setup-sh they must have\ntheir own.\n\nThis would make difference if/when we switch to\n/usr/lib/git/exec, but until then it is not.\n"},{"id":"17571","messageId":"7vacbrie79.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"7vek13ieap.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-15T21:35:22Z","receivedAt":"2006-03-15T21:35:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n(replying to myself ...)\n\n> Linus Torvalds <torvalds@osdl.org> writes:\n>\n>> I agree that it is inconsistent as-is. So a patch to make it use the \n>> \"git-repo-config\" form (the argument being that internally, we use the \n>> full names) might be good if just for consistency.\n>\n> If we do the dash-form for consistency's sake,...\n\nProbably I should add that personally my preference is to standardize on\nthe dashless form.\n"},{"id":"17572","messageId":"20060315221154.GA6494@localhost.localdomain","threadId":"3648","inReplyTo":"7vacbrie79.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.co.uk","sentAt":"2006-03-15T22:11:54Z","receivedAt":"2006-03-15T22:11:54Z","isPatch":true,"sender":{"key":"qhuo@mayhq.co.uk","avatar":null},"body":"On Wed, Mar 15, 2006 at 01:35:22PM -0800, Junio C Hamano wrote:\n> Junio C Hamano <junkio@cox.net> writes:\n> \n> > Linus Torvalds <torvalds@osdl.org> writes:\n> >\n> >> I agree that it is inconsistent as-is. So a patch to make it use the \n> >> \"git-repo-config\" form (the argument being that internally, we use the \n> >> full names) might be good if just for consistency.\n> >\n> > If we do the dash-form for consistency's sake,...\n> \n> Probably I should add that personally my preference is to standardize on\n> the dashless form.\n> \n\nThat would remove the possibility to run \"git-push\" in my scenario.  And\nwhat is the benefit?  Wasting CPU cycles to an extra execve?\nDuplicating git --exec-path to PATH?\n\nPersonally I recommend to always run git helper programs with absolute\npath, this would remove all confusions, not play with users' PATH\nenvironment, and save CPU cycles.\n\nQingning\n"},{"id":"17575","messageId":"Pine.LNX.4.64.0603151450070.3618@g5.osdl.org","threadId":"3648","inReplyTo":"7vek13ieap.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-15T22:51:30Z","receivedAt":"2006-03-15T22:51:30Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Mar 2006, Junio C Hamano wrote:\n> \n> If we do the dash-form for consistency's sake, we should do\n> PATH=\"`git --exec-path`:$PATH\" in git-setup-sh when/before we do\n> so.\n\nYes. That would make sense too. Then git-setup-sh would look more like \nwhat the builtin git.c does.\n\n\t\tLinus\n"},{"id":"17577","messageId":"7vlkvbffhz.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"Pine.LNX.4.64.0603151450070.3618@g5.osdl.org","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-15T23:35:36Z","receivedAt":"2006-03-15T23:35:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Wed, 15 Mar 2006, Junio C Hamano wrote:\n>> \n>> If we do the dash-form for consistency's sake, we should do\n>> PATH=\"`git --exec-path`:$PATH\" in git-setup-sh when/before we do\n>> so.\n>\n> Yes. That would make sense too. Then git-setup-sh would look more like \n> what the builtin git.c does.\n\nI think some historical background is in order.\n\nWe started without bindir vs execdir distinction but we wanted a\nway to someday migrate out of putting everything in bindir.  As\none part of the solution, \"git\" wrapper was invented, and as the\nresult of that effort, some parts of the scripts, and lot of\ndocumentation pages and sample scripts, lost dashes.\n\nHistorically, git tools have always wanted everything git-* to\nbe found on user's PATH, and we were alarmed to see 100+ git-*\ncommands in /usr/bin.  That's why \"git\" wrapper and\nGIT_EXEC_PATH environment were invented.  People can have\n/usr/bin/git and no other git-* on their PATH, because that\n\"git\" knows where to find the rest of git-* commands.  For that\nto work, the scripts should know where to find the rest -- and\ncleanest way is to run others via \"git foo\" form.\n\nConsistency via s/git-foo/git foo/g _is_ the goal, but that kind\nof change interferes with the other patches that do the real\nwork, and it is kind of boring, so nobody has done wholesale\nclean-up of all the scripts.\n\nInvoking with the full path is not an option -- it makes\nbuilding and testing-before-installing process too cumbersome.\nYou are welcome to try and send in a patch to do that if (and\nonly if) you volunteer to go the whole nine yards, but I have to\nwarn you that that approach is something we have already\nconsidered and discarded, one reason why is because it makes the\ntestsuite unworkable (testing needs to be done before\ninstalling).\n\nIf you want to use the other \"git\" (GNU interactive tools, which\nI once heard is changing its name to gitfm or something like\nthat -- how nice of them -- but has it ever happened?), and if\nyou want to have /usr/bin (which has that \"git\") and then\n/other/bin (which has on-topic \"git\") on your PATH, in that\norder, that would be a problem.  Saying just \"git\" would invoke\nother \"git\" that does not know what to do.\n\nIf you can solve that without hardcoding the full path in our\nscripts, that would be ideal.  But otherwise, especially with\nchanging things back to \"git-foo\" form without making sure going\nbackward in that way would not hinder the migration out of\n/usr/bin, then that creates more problems than it solves.\n\nSo that is why I said I would prefer dashless form.\n\nI _think_ the simplest fix is to change the order of directories\nyou list on your PATH so that \"git\" is found before GNU\ninteractive tool, which is my impression that most people seem\nto do (many in fact do not have GNU interactive tool on their\nPATH anywhere).\n"},{"id":"17581","messageId":"7voe06dhey.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"Pine.LNX.4.64.0603151450070.3618@g5.osdl.org","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-16T06:37:09Z","receivedAt":"2006-03-16T06:37:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Wed, 15 Mar 2006, Junio C Hamano wrote:\n>> \n>> If we do the dash-form for consistency's sake, we should do\n>> PATH=\"`git --exec-path`:$PATH\" in git-setup-sh when/before we do\n>> so.\n>\n> Yes. That would make sense too. Then git-setup-sh would look more like \n> what the builtin git.c does.\n\nI actually think what git.c does is _wrong_.\n\nBelieve it or not, there are people with bizarre configurations\njust like Qingning's is bizarre in different sense [*1*].  They\nhave diff they do not like (either broken or inadequete)\ninstalled under /usr/bin, and they install GNU diff under\n/home/$u/bin, and have their PATH set so that /home/$u/bin/diff\nis found before /usr/bin/diff (up to here, there is nothing\nbizarre).  However, somehow they have the latest \"git\" installed\nunder /usr/bin (this _is_ the bizarre part).\n\nEarlier, we prepended GIT_EXEC_PATH to user-supplied PATH when\nC-level routines needed to exec git programs.  This breaks that\n\"bizarre\" setup -- for such a setup, GIT_EXEC_PATH is currently\nset to /usr/bin and when we try to exec \"diff\", we ended up\nrunning /usr/bin/diff.  So in order to work this around, we\nintroduced exec[vl]_git_cmd() wrappers which use --exec-path\n(if the command supports per invocation override), GIT_EXEC_PATH\nenvironment, and then gitexecdir in Makefile when it was built,\nin this order.  \"git\" wrapper should know about this, but the\nolder code was never removed when we introduced exec_cmd.c.\n\nI think we need to do something like the attached patch.\n\n[Footnote]\n\n*1* I first wrote \"configuration even more bizarre than\nQingning's\", but before sending the message out I came to\nsenses.  We have to admit that that configuration is quite\nunusual, and I would say it is the one more bizarre than the one\nin question here.  When people have standard system executable\ndirectories such as /usr/bin and /bin and private directories\nlike /home/$u/bin and /usr/local/bin on their PATH, private\ndirectories always come before the system directories, so that\nthings in the system directories (often you do not have write\npermission to) can be overriden by private directories (which is\nunder your control).\n\n-- >8 --\n\ndiff --git a/git.c b/git.c\nindex 0b40e30..25e6a4e 100644\n--- a/git.c\n+++ b/git.c\n@@ -219,25 +219,6 @@ static void cmd_usage(int show_all, cons\n \texit(1);\n }\n \n-static void prepend_to_path(const char *dir, int len)\n-{\n-\tchar *path, *old_path = getenv(\"PATH\");\n-\tint path_len = len;\n-\n-\tif (!old_path)\n-\t\told_path = \"/usr/local/bin:/usr/bin:/bin\";\n-\n-\tpath_len = len + strlen(old_path) + 1;\n-\n-\tpath = malloc(path_len + 1);\n-\n-\tmemcpy(path, dir, len);\n-\tpath[len] = ':';\n-\tmemcpy(path + len + 1, old_path, path_len - len);\n-\n-\tsetenv(\"PATH\", path, 1);\n-}\n-\n static void show_man_page(const char *git_cmd)\n {\n \tconst char *page;\n@@ -447,18 +428,6 @@ int main(int argc, const char **argv, ch\n \t}\n \targv[0] = cmd;\n \n-\t/*\n-\t * We search for git commands in the following order:\n-\t *  - git_exec_path()\n-\t *  - the path of the \"git\" command if we could find it\n-\t *    in $0\n-\t *  - the regular PATH.\n-\t */\n-\tif (exec_path)\n-\t\tprepend_to_path(exec_path, strlen(exec_path));\n-\texec_path = git_exec_path();\n-\tprepend_to_path(exec_path, strlen(exec_path));\n-\n \t/* See if it's an internal command */\n \thandle_internal_command(argc, argv, envp);\n \n"},{"id":"17582","messageId":"20060316075324.GA19650@pfit.vm.bytemark.co.uk","threadId":"3648","inReplyTo":"7vlkvbffhz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.org","sentAt":"2006-03-16T07:53:24Z","receivedAt":"2006-03-16T07:53:24Z","isPatch":true,"sender":{"key":"qhuo@mayhq.org","avatar":null},"body":"On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > On Wed, 15 Mar 2006, Junio C Hamano wrote:\n> >> \n> >> If we do the dash-form for consistency's sake, we should do\n> >> PATH=\"`git --exec-path`:$PATH\" in git-setup-sh when/before we do\n> >> so.\n> >\n> > Yes. That would make sense too. Then git-setup-sh would look more like \n> > what the builtin git.c does.\n> \n> I think some historical background is in order.\n> \n> We started without bindir vs execdir distinction but we wanted a\n> way to someday migrate out of putting everything in bindir.  As\n> one part of the solution, \"git\" wrapper was invented, and as the\n> result of that effort, some parts of the scripts, and lot of\n> documentation pages and sample scripts, lost dashes.\n> \n> Historically, git tools have always wanted everything git-* to\n> be found on user's PATH, and we were alarmed to see 100+ git-*\n> commands in /usr/bin.  That's why \"git\" wrapper and\n> GIT_EXEC_PATH environment were invented.  People can have\n> /usr/bin/git and no other git-* on their PATH, because that\n> \"git\" knows where to find the rest of git-* commands.  For that\n> to work, the scripts should know where to find the rest -- and\n> cleanest way is to run others via \"git foo\" form.\n> \n> Consistency via s/git-foo/git foo/g _is_ the goal, but that kind\n> of change interferes with the other patches that do the real\n> work, and it is kind of boring, so nobody has done wholesale\n> clean-up of all the scripts.\n\nThanks for the historical background.\n\n> Invoking with the full path is not an option -- it makes\n> building and testing-before-installing process too cumbersome.\n> You are welcome to try and send in a patch to do that if (and\n> only if) you volunteer to go the whole nine yards, but I have to\n> warn you that that approach is something we have already\n> considered and discarded, one reason why is because it makes the\n> testsuite unworkable (testing needs to be done before\n> installing).\n\nSo we recognize the full path approach is desired, but because of\ntechnique reasons (building and testing), it is not applied.  I would\nlike to have a look of the said patch.  Can you give me some pointers?\n\n> If you want to use the other \"git\" (GNU interactive tools, which\n> I once heard is changing its name to gitfm or something like\n> that -- how nice of them -- but has it ever happened?), and if\n> you want to have /usr/bin (which has that \"git\") and then\n> /other/bin (which has on-topic \"git\") on your PATH, in that\n> order, that would be a problem.  Saying just \"git\" would invoke\n> other \"git\" that does not know what to do.\n\nThis is exactly the problem I want to solve.  In this case, I alias git\nto use our git program.\n\n> If you can solve that without hardcoding the full path in our\n> scripts, that would be ideal.  But otherwise, especially with\n> changing things back to \"git-foo\" form without making sure going\n> backward in that way would not hinder the migration out of\n> /usr/bin, then that creates more problems than it solves.\n\nWe do not hard code the full path in the script.  We can use a function\ngitexec() (in git-sh-setup) similiar to execv_git_cmd().  gitexec\nsearches git-command in GIT_EXEC_PATH, and then libexedir.  libexedir is\nhardcoded in git-sh-setup.  But can be override by the environment\nGIT_EXEC_PATH.  The make test target should set GIT_EXEC_PATH to the\nbuild directory.\n\nThe remaining job is search and replace.  If we call gitexec() git(), we\ncan even keep the \"git command\" form unchanged.  But I prefer explicit\ngitexec().\n\n> I _think_ the simplest fix is to change the order of directories\n> you list on your PATH so that \"git\" is found before GNU\n> interactive tool, which is my impression that most people seem\n> to do (many in fact do not have GNU interactive tool on their\n> PATH anywhere).\n\nI cannot uninstall /usr/bin/git.  It is not under my control.  I am\nwondering whether I should move my home dir to the front of the PATH.\nBut a good tool should not force users to change their settings.\n\nQingning\n"},{"id":"17583","messageId":"7vslpibz4w.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"20060316075324.GA19650@pfit.vm.bytemark.co.uk","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-16T07:57:19Z","receivedAt":"2006-03-16T07:57:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Qingning Huo <qhuo@mayhq.org> writes:\n\n> I cannot uninstall /usr/bin/git.  It is not under my control.  I am\n> wondering whether I should move my home dir to the front of the PATH.\n\nThat's what I found your configuration quite unusual.\n\nWhen people have standard system executable directories such as\n/usr/bin and /bin and private directories like /home/$u/bin and\n/usr/local/bin on their PATH, private directories always come\nbefore the system directories, so that things in the system\ndirectories (often you do not have write permission to) can be\noverriden by private directories (which is under your control).\nI've never seen anybody sane to have system path before private\nones.\n"},{"id":"17584","messageId":"7v64mebxsu.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"20060316075324.GA19650@pfit.vm.bytemark.co.uk","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-16T08:26:09Z","receivedAt":"2006-03-16T08:26:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Qingning Huo <qhuo@mayhq.org> writes:\n\n> So we recognize the full path approach is desired,\n\nI said \"if you can work problems your environment has _without_\ndoing the full path thing, then it would be ideal\".\n\nI never said full path is desired -- I despise full path, in\nfact.  It makes certain things very inconvenient.\n\n> ...but because of\n> technique reasons (building and testing), it is not applied.\n\nThere were not even a patch.  I suspect people involved in the\ndiscussion realized that approach was unworkably cumbersome.\n\nIn our Makefile, we have sed script mechanism to replace tokens\nso we _could_ change our sources to do something like this:\n\n        diff --git a/git-commit.sh b/git-commit.sh\n        index 330a434..10835c6 100755\n        --- a/git-commit.sh\n        +++ b/git-commit.sh\n\t...\n        @@ -115,7 +115,7 @@ run_status () {\n                    echo '#\n         # Initial commit\n         #'\n        -\t    git-ls-files |\n        +\t    @@GIT_PATH@@git-ls-files |\n                    sed -e '\n                            s/\\\\/\\\\\\\\/g\n                            s/ /\\\\ /g\n        @@ -126,7 +126,7 @@ run_status () {\n                    committable=\"$?\"\n                fi\n\n        -\tgit-diff-files --name-status |\n        +\t@@GIT_PATH@@git-diff-files --name-status |\n                sed -e '\n                        s/\\\\/\\\\\\\\/g\n                        s/ /\\\\ /g\n\t...\n\nand sed it out with 's/@@GIT_PATH@@/$(gitexecdir_SQ)/g'.\n\nHowever, you have to realize that I often want to try things out\n*without* running \"make\", let alone installing.  The current way\nthings are set up lets me say:\n\n\t$ GIT_EXEC_PATH=$my_git_source \\\n          sh -x $my_git_source/git-commit.sh\n\nto see where things break.  Changing things the way I quoted\nabove would make things _extremely_ inconvenient for me.\n\nAnd it is ugly.  \"Making things ugly and inconvenient for what\npurpose?\" is the question I have to ask myself at this point.\n\nAnd if the answer is \"to support unusual configuration which,\nquite frankly, I think is broken\", then...\n\nWe could probably define a shell function that looks like:\n\n        git_exec () {\n                cmd=\"$1\"\n                shift\n                case \"${GIT_EXEC_PATH+set}\" in\n                set) ;;\n                *) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;\n                esac\n                \"$GIT_EXEC_PATH/git-$cmd\" \"$@\"\n        }\n\nin git-sh-setup [*1*], and then rewrite the above to something\nlike this instead:\n\n        diff --git a/git-commit.sh b/git-commit.sh\n        index 330a434..8a73420 100755\n        --- a/git-commit.sh\n        +++ b/git-commit.sh\n        ...\n        @@ -115,7 +115,7 @@ run_status () {\n                    echo '#\n         # Initial commit\n         #'\n        -\t    git-ls-files |\n        +\t    git_exec ls-files |\n                    sed -e '\n                            s/\\\\/\\\\\\\\/g\n                            s/ /\\\\ /g\n        @@ -126,7 +126,7 @@ run_status () {\n                    committable=\"$?\"\n                fi\n\n        -\tgit-diff-files  --name-status |\n        +\tgit_exec diff-files  --name-status |\n                sed -e '\n                        s/\\\\/\\\\\\\\/g\n                        s/ /\\\\ /g\n        ...\n\nBut that does not cover Perl nor Python scripts, and does not\naddress the ugliness either.\n\n\n[Footnote]\n\n*1* BTW, I just noticed that git-sh-setup needs to be on user's\nPATH, so we probably have to inline and duplicate the git_exec()\nshell function definition at the beginning of each script after\nall, when we make the initial \". git-sh-setup\" inclusion to\nhonor GIT_EXEC_PATH without munging the user's PATH.\n\nWhich is not a big deal by itself, since we preprocess\n*.{sh,perl,py} files anyway, but still it leaves a _big_\nugliness factor.\n"},{"id":"17585","messageId":"7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"20060316075324.GA19650@pfit.vm.bytemark.co.uk","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-16T10:14:52Z","receivedAt":"2006-03-16T10:14:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Qingning Huo <qhuo@mayhq.org> writes:\n\n> On Wed, Mar 15, 2006 at 03:35:36PM -0800, Junio C Hamano wrote:\n>> I think some historical background is in order.\n>> ...\n> Thanks for the historical background.\n\nSorry, it just occurred to me that I was totally confused, and I\napologize for giving only half of the historical background,\nwithout giving the \"end of the story -- conclusion\", which I did\nnot remember until now.\n\nWhat we ended up deciding after that \"My /usr/bin/git is sane\nbut /usr/bin/diff is wrong so I have /home/$u/bin/diff and\n/home/$u/bin is listed earlier in my $PATH\" discussion, as I\nremember, was this:\n\n * We expect users to invoke things on the command line via the\n   \"git\" wrapper.  Either having the directory that has our\n   \"git\" in earlier on the PATH, or giving the full path to it\n   as the command (your use of alias qualifies as the latter).\n\n * One of the important things the \"git\" wrapper does is to\n   prefix GIT_EXEC_PATH to the $PATH environment before invoking\n   the \"git-foo\" commands [*1*].  \n\n * \"git-foo\" command, if it is written in a scripting language,\n   can safely assume \"git-bar\" is found on the PATH while it is\n   executing.  If it is C-level and uses exec[vl]_git_cmd() to\n   run the subcommand, it would also work fine (it will use the\n   right GIT_EXEC_PATH).\n\nThis has a few implications:\n\n * By doing the above setup, we are effectively punting on the\n   original issue.  First of all, it is very inconceivable that\n   /usr/bin/git is sane, and /usr/bin/diff is not (git wants a\n   working diff after all).  If the user is overriding\n   /usr/bin/diff by having a better diff under /home/$u/bin/, he\n   could have his own copy of git under /home/$u/bin/ as well\n   (more likely, the person with correct privilege to installed\n   /usr/bin/git would have replaced faulty /usr/bin/diff).  More\n   importantly, when bindir and gitexecdir are split, gitexecdir\n   will not be /usr/bin (bindir will be).  It will more likely\n   to be /usr/lib/git/exec, and it would contain only git-*\n   things; prefixing that directory to PATH would not mask the\n   /home/$u/bin/diff or anything else non-git the user wanted to\n   mask stuff from /usr/bin with, so the original issue becomes\n   moot at that point.\n\n * Typing \"git-foo\" on the command line would work most of the\n   time, if git is built with gitexecdir set to standard bin\n   directory (the way our Makefile is shipped).  git-foo will be\n   found on your PATH, and it will find \"git-bar\" on your PATH.\n   However, when we split bindir and gitexecdir, typing\n   \"git-foo\" on the command line without having GIT_EXEC_PATH on\n   your PATH would stop working, so users have been encouraged\n   to train their fingers to use dashless form ever since\n   GIT_EXEC_PATH was introduced [*2*].\n\n * If \"git-foo\" invoked from the command line (without necessary\n   GIT_EXEC_PATH prefixing done by the \"git\" wrapper) tries to\n   run \"git\", the right git needs to be found on your PATH,\n   otherwise things may not necessarily work (your setup\n   violates this).  But people have been encouraged to say \"git\n   foo\" to begin with, so this is probably not a big\n   deal. Retraining people to say \"git foo\" instead of \"git-foo\"\n   is a bigger issue compared to this.\n\n * If \"git foo\" is typed on the command line, underlying\n   \"git-foo\" is run with GIT_EXEC_PATH prefixed, so it will find\n   \"git-bar\".  If the script uses \"git bar\", \"git\" needs to be\n   found either in GIT_EXEC_PATH or on your PATH, since our\n   Makefile does not install \"git\" in gitexecdir.  Right now, we\n   have bindir == gitexecdir, so \"git bar\" in \"git-foo\" script\n   will work fine and this is a non-issue, but when we split\n   them, it will break your setup, so we need to address this\n   before that happens.\n\nSo in short, there are two real issues with your original\n\"git-push misbehaves\".  One is that it broke because it was\nspelled with dash.  I think \"git push\" shouldn't misbehave even\nwith your setup, because the \"git\" wrapper, before it calls\n\"git-push\", should set up the PATH so that its exec-path is in\nfront of anything you have in your original PATH (either\n/usr/bin or ~/opt/bin), and should find the right \"git\".\n\nAnd the second issue is the last point in the \"implications\"\nlist above.  You are right, and I stand corrected.  Our scripts\nshould consistently use dash form.\n\nOne thing that bothers me is that we need to keep encouraging\nusers to use dashless form from the command line, while we\nupdate our scripts to use dash form.  What a contradicting and\nconfusing situation X-<.\n\n\n[Footnote]\n\n*1* The \"remove prefixing from git.c\" patch I sent out earlier\ntonight is wrong.  That's the crucial piece to make this whole\nsetup work.\n\n*2* I think I've been careful enough to use dashless form in the\nexamples I give in my list postings, but I am not sure how\nsuccessful I have been.\n"},{"id":"17586","messageId":"4419524B.1030405@op5.se","threadId":"3648","inReplyTo":"7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-16T11:55:55Z","receivedAt":"2006-03-16T11:55:55Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> And the second issue is the last point in the \"implications\"\n> list above.  You are right, and I stand corrected.  Our scripts\n> should consistently use dash form.\n> \n> One thing that bothers me is that we need to keep encouraging\n> users to use dashless form from the command line, while we\n> update our scripts to use dash form.  What a contradicting and\n> confusing situation X-<.\n> \n\nOne of the two reasons for rewriting the git wrapper in C was the \nperformance penalty that came from having it as a shell-script while it \nwas desirable from a porcelainish standpoint to use the dash-less form \nsince we thought even then that \"git\" would always be in PATH while \n\"git-foo\" was to be moved to the still-imaginary GIT_EXEC_PATH.\n\nThe prepending of the GIT_EXEC_PATH to PATH was a laziness workaround \nfor scripts that use the dashed form until we'd had time to change \nthose, although I see from the commit-message that it's a far cry from \nabundantly clear (reading it now I even think it's clear I meant the \nother way around, although I remember I didn't). Anyways, the relative \nparts are these, from commit 8e49d50388211a0f3e7286f6ee600bf7736f4814\n\n---8<---8<---8<---\n     The location of the GIT_EXEC_PATH (name discussion's closed,\n     thank gods) can be obtained by running\n\n     \tgit --exec-path\n\n     which will hopefully give porcelainistas ample time to adapt their\n     heavy-duty loops to call the core programs directly and thus save\n     the extra fork() / execve() overhead, although that's not really\n     necessary any more.\n\n     The --exec-path value is prepended to $PATH, so the git-* programs\n     should Just Work without ever requiring any changes to how they call\n     other programs in the suite.\n\n     Some timing values for 10000 invocations of git-var >&/dev/null:\n     \tgit.sh: 24.194s\n     \tgit.c:   9.044s\n     \tgit-var: 7.377s\n\n---8<---8<---8<---\n\n From the timing values there I think the performance issues of using \nthe dash-less form can just be ignored. Very rarely will a porcelainish \nwrapper do 10000 invocations of git commands where less than 2 seconds \nwill be a large percentage of the overall runtime.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17587","messageId":"slrne1inu0.fr9.mdw@metalzone.distorted.org.uk","threadId":"3648","inReplyTo":"7v64mebxsu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-16T12:53:20Z","receivedAt":"2006-03-16T12:53:20Z","isPatch":true,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n\n> *1* BTW, I just noticed that git-sh-setup needs to be on user's\n> PATH, so we probably have to inline and duplicate the git_exec()\n> shell function definition at the beginning of each script after\n> all, when we make the initial \". git-sh-setup\" inclusion to\n> honor GIT_EXEC_PATH without munging the user's PATH.\n\n. ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup\n\nisn't too grim, and shows how the git_exec shell function can be made\nsomewhat terser.\n\nBy the way, am I the only person who /likes/ having all the git-*\nprograms on his path?  It makes shell completion work fairly well\nwithout having to install strange completion scripts which get out of\ndate for one thing.\n\n-- [mdw]\n"},{"id":"17588","messageId":"44196DE7.8010205@op5.se","threadId":"3648","inReplyTo":"slrne1inu0.fr9.mdw@metalzone.distorted.org.uk","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-16T13:53:43Z","receivedAt":"2006-03-16T13:53:43Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Mark Wooding wrote:\n> Junio C Hamano <junkio@cox.net> wrote:\n> \n> \n>>*1* BTW, I just noticed that git-sh-setup needs to be on user's\n>>PATH, so we probably have to inline and duplicate the git_exec()\n>>shell function definition at the beginning of each script after\n>>all, when we make the initial \". git-sh-setup\" inclusion to\n>>honor GIT_EXEC_PATH without munging the user's PATH.\n> \n> \n> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup\n> \n> isn't too grim, and shows how the git_exec shell function can be made\n> somewhat terser.\n> \n\nBut it breaks the convenience when testing.\n\n> By the way, am I the only person who /likes/ having all the git-*\n> programs on his path?  It makes shell completion work fairly well\n> without having to install strange completion scripts which get out of\n> date for one thing.\n> \n\nI like it too, but I don't use it unless I can't remember what the \ncommand was named (finger-training). It shouldn't be too difficult to \nmake git.c write its own auto-generated bash-completion rules. If \nsomeone would care to teach me the syntax I'd gladly hack up a patch for \nit. This is a Good Thing, since it means it would also work for the \ninternal commands, which bash's path-completion doesn't.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17589","messageId":"20060316162709.6f383f95.tihirvon@gmail.com","threadId":"3648","inReplyTo":"slrne1inu0.fr9.mdw@metalzone.distorted.org.uk","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Timo Hirvonen","fromEmail":"tihirvon@gmail.com","sentAt":"2006-03-16T14:27:09Z","receivedAt":"2006-03-16T14:27:09Z","isPatch":true,"sender":{"key":"tihirvon@gmail.com","avatar":null},"body":"On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)\nMark Wooding <mdw@distorted.org.uk> wrote:\n\n> By the way, am I the only person who /likes/ having all the git-*\n> programs on his path?  It makes shell completion work fairly well\n> without having to install strange completion scripts which get out of\n> date for one thing.\n\nI like git-* for the same reason.  But if git potty had aliases for long\ncommands then git-* commands would become irrelevant.  Especially\n\"git co\" would be nice.  It even would be faster to type than\ngit-ch<tab>c<tab>o<tab> ;)\n\n-- \nhttp://onion.dynserv.net/~timo/\n"},{"id":"17591","messageId":"441978B9.6090301@op5.se","threadId":"3648","inReplyTo":"20060316162709.6f383f95.tihirvon@gmail.com","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-16T14:39:53Z","receivedAt":"2006-03-16T14:39:53Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Timo Hirvonen wrote:\n> On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)\n> Mark Wooding <mdw@distorted.org.uk> wrote:\n> \n> \n>>By the way, am I the only person who /likes/ having all the git-*\n>>programs on his path?  It makes shell completion work fairly well\n>>without having to install strange completion scripts which get out of\n>>date for one thing.\n> \n> \n> I like git-* for the same reason.  But if git potty had aliases for long\n> commands then git-* commands would become irrelevant.  Especially\n> \"git co\" would be nice.  It even would be faster to type than\n> git-ch<tab>c<tab>o<tab> ;)\n> \n\nIt would indeed, and it should also be fairly trivial. However, adding \nshort-hands that are identical with cvs and svn but does a totally \ndifferent thing (well, not really different, but cvs users will be \nsurprised) is not necessarily a good thing.\n\nIt would be better, imo, to add ambiguity detection for commands that \nlacks an exact match. That way \"git br\" and \"git branch\" would be \nidentical and the logic only needs doing once. I'm not terribly excited \nabout it though, so...\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17598","messageId":"1142537257.17536.137.camel@cashmere.sps.mot.com","threadId":"3648","inReplyTo":"7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-03-16T19:27:37Z","receivedAt":"2006-03-16T19:27:37Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Thu, 2006-03-16 at 04:14, Junio C Hamano wrote:\n\n> And the second issue is the last point in the \"implications\"\n> list above.  You are right, and I stand corrected.  Our scripts\n> should consistently use dash form.\n> \n> One thing that bothers me is that we need to keep encouraging\n> users to use dashless form from the command line, while we\n> update our scripts to use dash form.  What a contradicting and\n> confusing situation X-<.\n\nI think it has a philosophical rationale, though.\n\nWhile we want to proved an abstraction layer to the\nuser through the \"git\" wrapper, we still want to be\nprecise internally within the scripts themselves.\n\nOr so.\n\njdl\n"},{"id":"17599","messageId":"1142537528.17536.143.camel@cashmere.sps.mot.com","threadId":"3648","inReplyTo":"1142537257.17536.137.camel@cashmere.sps.mot.com","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-03-16T19:32:09Z","receivedAt":"2006-03-16T19:32:09Z","isPatch":true,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Thu, 2006-03-16 at 13:27, Jon Loeliger wrote:\n\n> While we want to proved an abstraction layer to the\n> user through the \"git\" wrapper, we still want to be\n> precise internally within the scripts themselves.\n\nHey!  Nice English there, Jon!\n\ns/proved/provide\n\njdl\n"},{"id":"17600","messageId":"20060316203319.GA20159@localhost.localdomain","threadId":"3648","inReplyTo":"7v64mebxsu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Qingning Huo","fromEmail":"qhuo@mayhq.org","sentAt":"2006-03-16T20:33:19Z","receivedAt":"2006-03-16T20:33:19Z","isPatch":true,"sender":{"key":"qhuo@mayhq.org","avatar":null},"body":"On Thu, Mar 16, 2006 at 12:26:09AM -0800, Junio C Hamano wrote:\n> \n> We could probably define a shell function that looks like:\n> \n>         git_exec () {\n>                 cmd=\"$1\"\n>                 shift\n>                 case \"${GIT_EXEC_PATH+set}\" in\n>                 set) ;;\n>                 *) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;\n>                 esac\n>                 \"$GIT_EXEC_PATH/git-$cmd\" \"$@\"\n>         }\n> \n> in git-sh-setup [*1*], and then rewrite the above to something\n> like this instead:\n> \n>         diff --git a/git-commit.sh b/git-commit.sh\n>         index 330a434..8a73420 100755\n>         --- a/git-commit.sh\n>         +++ b/git-commit.sh\n>         ...\n>         @@ -115,7 +115,7 @@ run_status () {\n>                     echo '#\n>          # Initial commit\n>          #'\n>         -\t    git-ls-files |\n>         +\t    git_exec ls-files |\n>                     sed -e '\n>                             s/\\\\/\\\\\\\\/g\n>                             s/ /\\\\ /g\n>         @@ -126,7 +126,7 @@ run_status () {\n>                     committable=\"$?\"\n>                 fi\n> \n>         -\tgit-diff-files  --name-status |\n>         +\tgit_exec diff-files  --name-status |\n>                 sed -e '\n>                         s/\\\\/\\\\\\\\/g\n>                         s/ /\\\\ /g\n>         ...\n> \n> But that does not cover Perl nor Python scripts, and does not\n> address the ugliness either.\n\nThis is similiar to what I had in mind when I recommended the full path\napproach.  Perl or Python should be able to do the similiar.  I have no\ncomment on the ugliness.  The functionality and effeciency of the\nprogram is more important to me.  But I do recognize the difficulties of\nchanging all scripts overnight.\n\nAnyway, there are at least other two ways to solve my problem.  (a)\nsetup PATH in git-sh-setup, or (b) consistently use git-command form in\nscripts.  Even before their implementation, I can still use \"git push\".  \n\nQingning\n"},{"id":"17602","messageId":"7vy7z97rdr.fsf@assigned-by-dhcp.cox.net","threadId":"3648","inReplyTo":"44196DE7.8010205@op5.se","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-17T02:10:40Z","receivedAt":"2006-03-17T02:10:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n>> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup\n>> isn't too grim, and shows how the git_exec shell function can be made\n>> somewhat terser.\n>\n> But it breaks the convenience when testing.\n\nI think that's OK.  When I test things in the build directory\nwithout installing I would usually do:\n\n\t$ GIT_EXEC_PATH=`pwd` PATH=`pwd`:/usr/bin:/bin ./git-cmd-to-test\n\nand the above would not break things.\n"},{"id":"17618","messageId":"slrne1l55l.fr9.mdw@metalzone.distorted.org.uk","threadId":"3648","inReplyTo":"7vy7z97rdr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Invoke git-repo-config directly.","fromName":"Mark Wooding","fromEmail":"mdw@distorted.org.uk","sentAt":"2006-03-17T10:51:33Z","receivedAt":"2006-03-17T10:51:33Z","isPatch":true,"sender":{"key":"mdw@distorted.org.uk","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n\n> and the above would not break things.\n\nIndeed.  I just translated Junio's `git_exec' shell function into a\none-liner.\n\n-- [mdw]\n"}]}