{"thread":{"id":"2360","subject":"git binary directory?","startedAt":"2005-11-05T21:02:23Z","lastAt":"2005-11-10T09:49:31Z","messageCount":17,"participants":["Linus Torvalds","Junio C Hamano","Petr Baudis","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11175","messageId":"Pine.LNX.4.64.0511051247330.3316@g5.osdl.org","threadId":"2360","inReplyTo":null,"subject":"git binary directory?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-05T21:02:23Z","receivedAt":"2005-11-05T21:02:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nJust for fun, I did \"git-<tab><tab>\" a moment ago, and it asked me\n\n\tDisplay all 171 possibilities? (y or n)\n\nwhich was a bit scary. Now, part of that was because I hadn't cleaned up \nthe old git names, so I removed everything, and did a clean \"make install\" \nwith the current git tree. At which point the question became\n\n\tDisplay all 105 possibilities? (y or n)\n\nand pressing \"y\" shows a really nice list of programs.\n\nNow, this is actually very convenient, and since I tend to install things \nin my own ~/bin directory, it's all good. What's a hundred files more or \nless?\n\nHowever, doing a \"ls /usr/bin/ | wc\" shows that on my laptop /usr/bin is \nalready 2583 files, and git is actually part of the problem there (hey, \nit's got the git RPM installed - it's not my main machine)..\n\nNow, I happen to think that 2500+ files in /usr/bin is a bit much (ever \ntry to use the horrid gnome executable finder on it when you want to \nconvince firefox to use xpdf instead of that broken crap called \"evince\"? \nTakes absolutely ages and is horrible).\n\nAnd git made it about 4% worse all on its own.\n\nSo I'd really suggest that while the \"git-<tab><tab>\" thing is perhaps \nuseful, we'd actually be better off with an /usr/lib/git directory where \nwe put the git executables by default. And just put \"git\" into /usr/bin.\n\nThat way, people who _want_ to use \"git-<tab><tab>\" can just add the git \nbinary directory to their path and directly access all of them. And others \ncan just use the plain \"git\" interface.\n\nThat would mean that I'd have to learn to use \"git whatchanged\" and \"git \ndiff-tree\" instead of \"git-whatchanged\" and \"git-diff-tree\", but hey, it's \nwhy we have that \"git\" script in the first place.\n\nWhat do people think?\n\n\t\t\tLinus\n"},{"id":"11177","messageId":"Pine.LNX.4.64.0511051535220.3316@g5.osdl.org","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511051247330.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-05T23:52:16Z","receivedAt":"2005-11-05T23:52:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 Nov 2005, Linus Torvalds wrote:\n> \n> So I'd really suggest that while the \"git-<tab><tab>\" thing is perhaps \n> useful, we'd actually be better off with an /usr/lib/git directory where \n> we put the git executables by default. And just put \"git\" into /usr/bin.\n\nThis is a guaranteed BUGGY thing to make the git RPM do something like \nthat.\n\nIt adds a \"gitdir\" parameter to \"make install\", which defaults to the same \nas \"bindir\" if you don't specify it.\n\nIt installs only \"git\" in \"bindir\", and all other git programs in \n\"gitdir\".\n\nIt then makes the \"git\" script use \"gitdir\" for searching for the \ninstalled git scripts and programs, and forces PATH to have \"gitdir\" at \nthe head while executing the sub-script (so that when the scripts do \n\"git-diff-tree\" etc, they'll always use the proper gitdir version).\n\nThe RPM specfile is taught to make \"gitdir\" be \"${_libdir}/git-@@VERSION\"\n\nThis means that if I got everything right, the RPM will build with\n\n\t/usr/bin/git\n\n\t/usr/lib/git-0.99.9.GIT/git-add\n\t/usr/lib/git-0.99.9.GIT/git-am\n\t/usr/lib/git-0.99.9.GIT/git-apply\n\t..\n\n\t/usr/share/doc/git-core-0.99.9.GIT\n\t/usr/share/doc/git-core-0.99.9.GIT/COPYING\n\t..\n\n\t/usr/share/git-core\n\t/usr/share/git-core/python\n\t..\n\n\t/usr/share/git-core/templates\n\t/usr/share/git-core/templates/branches\n\t..\n\n\t/usr/share/man/man1/git-add.1.gz\n\t/usr/share/man/man1/git-am.1.gz\n\t..\n\nwhere the new thing is that \"/usr/lib/git-0.99.9.GIT/\" usage.\n\nI've tested building the rpm, and that part works. I haven't actually \ntested the end result, though.\n\nOh, and I have not a clue in hell about how Debian works. In fact, I don't \nhave a real clue how RPM files work either, this was done by doing some \npattern matching on the existing git-core.spec.in file. Somebody who knows \nbetter really should fix it.\n\nWARNING! I just realized that \"gitk\" also ends up in that /usr/lib/git.. \ndirectory, and this isn't visible. My bad. I'm a retard. \n\nComments?\n\nWhat do people think about this? Any daring souls willing to test this?\n\n(Btw: word of caution on something that confused me at first: you have to \n_commit_ this diff in order for \"make rpm\" to work, since \"make rpm\" uses \n\"git-tar-tree\" to create the rpm file, not the current directory contents, \nheh ;)\n\n\t\tLinus\n\n---\ndiff --git a/Makefile b/Makefile\nindex 6c01dc2..8df8b50 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -59,6 +59,7 @@ ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINE\n \n prefix = $(HOME)\n bindir = $(prefix)/bin\n+gitdir = $(bindir)\n template_dir = $(prefix)/share/git-core/templates/\n GIT_PYTHON_DIR = $(prefix)/share/git-core/python\n # DESTDIR=\n@@ -86,7 +87,7 @@ SCRIPT_SH = \\\n \tgit-prune.sh git-pull.sh git-push.sh git-rebase.sh \\\n \tgit-repack.sh git-request-pull.sh git-reset.sh \\\n \tgit-resolve.sh git-revert.sh git-sh-setup.sh git-status.sh \\\n-\tgit-tag.sh git-verify-tag.sh git-whatchanged.sh git.sh \\\n+\tgit-tag.sh git-verify-tag.sh git-whatchanged.sh \\\n \tgit-applymbox.sh git-applypatch.sh git-am.sh \\\n \tgit-merge.sh git-merge-stupid.sh git-merge-octopus.sh \\\n \tgit-merge-resolve.sh git-merge-ours.sh git-grep.sh\n@@ -315,7 +316,7 @@ SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)\n export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir\n ### Build rules\n \n-all: $(PROGRAMS) $(SCRIPTS)\n+all: git $(PROGRAMS) $(SCRIPTS)\n \n all:\n \t$(MAKE) -C templates\n@@ -323,6 +324,7 @@ all:\n git: git.sh Makefile\n \trm -f $@+ $@\n \tsed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \\\n+\t    -e 's:@@GITDIR@@:$(gitdir):g' \\\n \t    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n \t    -e 's/@@X@@/$(X)/g' \\\n \t    $(GIT_LIST_TWEAK) <$@.sh >$@+\n@@ -410,9 +412,11 @@ check:\n \n ### Installation rules\n \n-install: $(PROGRAMS) $(SCRIPTS)\n+install: git $(PROGRAMS) $(SCRIPTS)\n \t$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))\n-\t$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))\n+\t$(INSTALL) git $(call shellquote,$(DESTDIR)$(bindir))\n+\t$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitdir))\n+\t$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(gitdir))\n \t$(MAKE) -C templates install\n \t$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))\n \t$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))\ndiff --git a/git-core.spec.in b/git-core.spec.in\nindex 5240dd2..0d0ddf3 100644\n--- a/git-core.spec.in\n+++ b/git-core.spec.in\n@@ -19,17 +19,19 @@ distributed source code management syste\n rudimentary tools that can be used as a SCM, but you should look\n elsewhere for tools for ordinary humans layered on top of this.\n \n+%define gitdir %{_libdir}/git-@@VERSION@@\n+\n %prep\n %setup -q\n \n %build\n make %{_smp_mflags} CFLAGS=\"$RPM_OPT_FLAGS\" WITH_OWN_SUBPROCESS_PY=YesPlease \\\n-     prefix=%{_prefix} all %{!?_without_docs: doc}\n+     gitdir=%{gitdir} prefix=%{_prefix} all %{!?_without_docs: doc}\n \n %install\n rm -rf $RPM_BUILD_ROOT\n make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \\\n-     prefix=%{_prefix} mandir=%{_mandir} \\\n+     gitdir=%{gitdir} prefix=%{_prefix} mandir=%{_mandir} \\\n      install %{!?_without_docs: install-doc}\n \n %clean\n@@ -38,6 +40,7 @@ rm -rf $RPM_BUILD_ROOT\n %files\n %defattr(-,root,root)\n %{_bindir}/*\n+%{gitdir}/*\n %{_datadir}/git-core/\n %doc README COPYING Documentation/*.txt\n %{!?_without_docs: %doc Documentation/*.html }\ndiff --git a/git.sh b/git.sh\nindex 94940ae..9ba1608 100755\n--- a/git.sh\n+++ b/git.sh\n@@ -1,7 +1,8 @@\n #!/bin/sh\n \n cmd=\n-path=$(dirname \"$0\")\n+path=\"@@GITDIR@@\"\n+export PATH=\"$path:$PATH\"\n case \"$#\" in\n 0)\t;;\n *)\tcmd=\"$1\"\n"},{"id":"11178","messageId":"Pine.LNX.4.64.0511051625110.3316@g5.osdl.org","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511051535220.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-06T00:27:11Z","receivedAt":"2005-11-06T00:27:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 Nov 2005, Linus Torvalds wrote:\n> \n> This is a guaranteed BUGGY thing to make the git RPM do something like \n> that.\n>\n> [ ... ]\n> \n> WARNING! I just realized that \"gitk\" also ends up in that /usr/lib/git.. \n> directory, and this isn't visible. My bad. I'm a retard. \n\nThis fixes the gitk thing, by installing it (along with git) in the \nregular $prefix/bin directory (ie default /usr/bin for the RPM).\n\nI'm still a retard, and it's _probably_ still buggy, but at least it is no \nlonger GUARANTEED to be buggy.\n\n\t\tLinus\n\n---\ndiff --git a/Makefile b/Makefile\nindex 6c01dc2..6ec9dd2 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -59,6 +59,7 @@ ALL_CFLAGS = $(CFLAGS) $(PLATFORM_DEFINE\n \n prefix = $(HOME)\n bindir = $(prefix)/bin\n+gitdir = $(bindir)\n template_dir = $(prefix)/share/git-core/templates/\n GIT_PYTHON_DIR = $(prefix)/share/git-core/python\n # DESTDIR=\n@@ -86,7 +87,7 @@ SCRIPT_SH = \\\n \tgit-prune.sh git-pull.sh git-push.sh git-rebase.sh \\\n \tgit-repack.sh git-request-pull.sh git-reset.sh \\\n \tgit-resolve.sh git-revert.sh git-sh-setup.sh git-status.sh \\\n-\tgit-tag.sh git-verify-tag.sh git-whatchanged.sh git.sh \\\n+\tgit-tag.sh git-verify-tag.sh git-whatchanged.sh \\\n \tgit-applymbox.sh git-applypatch.sh git-am.sh \\\n \tgit-merge.sh git-merge-stupid.sh git-merge-octopus.sh \\\n \tgit-merge-resolve.sh git-merge-ours.sh git-grep.sh\n@@ -310,12 +311,12 @@ DEFINES += -DSHA1_HEADER=$(call shellquo\n SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \\\n \t  $(patsubst %.perl,%,$(SCRIPT_PERL)) \\\n \t  $(patsubst %.py,%,$(SCRIPT_PYTHON)) \\\n-\t  gitk git-cherry-pick\n+\t  git-cherry-pick\n \n export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir\n ### Build rules\n \n-all: $(PROGRAMS) $(SCRIPTS)\n+all: git gitk $(PROGRAMS) $(SCRIPTS)\n \n all:\n \t$(MAKE) -C templates\n@@ -323,6 +324,7 @@ all:\n git: git.sh Makefile\n \trm -f $@+ $@\n \tsed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \\\n+\t    -e 's:@@GITDIR@@:$(gitdir):g' \\\n \t    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n \t    -e 's/@@X@@/$(X)/g' \\\n \t    $(GIT_LIST_TWEAK) <$@.sh >$@+\n@@ -410,9 +412,11 @@ check:\n \n ### Installation rules\n \n-install: $(PROGRAMS) $(SCRIPTS)\n+install: git gitk $(PROGRAMS) $(SCRIPTS)\n \t$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(bindir))\n-\t$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(bindir))\n+\t$(INSTALL) git gitk $(call shellquote,$(DESTDIR)$(bindir))\n+\t$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(gitdir))\n+\t$(INSTALL) $(PROGRAMS) $(SCRIPTS) $(call shellquote,$(DESTDIR)$(gitdir))\n \t$(MAKE) -C templates install\n \t$(INSTALL) -d -m755 $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))\n \t$(INSTALL) $(PYMODULES) $(call shellquote,$(DESTDIR)$(GIT_PYTHON_DIR))\n@@ -450,7 +454,7 @@ deb: dist\n \n clean:\n \trm -f *.o mozilla-sha1/*.o ppc/*.o compat/*.o $(PROGRAMS) $(LIB_FILE)\n-\trm -f $(filter-out gitk,$(SCRIPTS))\n+\trm -f $(SCRIPTS)\n \trm -f git-core.spec *.pyc *.pyo\n \trm -rf $(GIT_TARNAME)\n \trm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz\ndiff --git a/git-core.spec.in b/git-core.spec.in\nindex 5240dd2..0d0ddf3 100644\n--- a/git-core.spec.in\n+++ b/git-core.spec.in\n@@ -19,17 +19,19 @@ distributed source code management syste\n rudimentary tools that can be used as a SCM, but you should look\n elsewhere for tools for ordinary humans layered on top of this.\n \n+%define gitdir %{_libdir}/git-@@VERSION@@\n+\n %prep\n %setup -q\n \n %build\n make %{_smp_mflags} CFLAGS=\"$RPM_OPT_FLAGS\" WITH_OWN_SUBPROCESS_PY=YesPlease \\\n-     prefix=%{_prefix} all %{!?_without_docs: doc}\n+     gitdir=%{gitdir} prefix=%{_prefix} all %{!?_without_docs: doc}\n \n %install\n rm -rf $RPM_BUILD_ROOT\n make %{_smp_mflags} DESTDIR=$RPM_BUILD_ROOT WITH_OWN_SUBPROCESS_PY=YesPlease \\\n-     prefix=%{_prefix} mandir=%{_mandir} \\\n+     gitdir=%{gitdir} prefix=%{_prefix} mandir=%{_mandir} \\\n      install %{!?_without_docs: install-doc}\n \n %clean\n@@ -38,6 +40,7 @@ rm -rf $RPM_BUILD_ROOT\n %files\n %defattr(-,root,root)\n %{_bindir}/*\n+%{gitdir}/*\n %{_datadir}/git-core/\n %doc README COPYING Documentation/*.txt\n %{!?_without_docs: %doc Documentation/*.html }\ndiff --git a/git.sh b/git.sh\nindex 94940ae..9ba1608 100755\n--- a/git.sh\n+++ b/git.sh\n@@ -1,7 +1,8 @@\n #!/bin/sh\n \n cmd=\n-path=$(dirname \"$0\")\n+path=\"@@GITDIR@@\"\n+export PATH=\"$path:$PATH\"\n case \"$#\" in\n 0)\t;;\n *)\tcmd=\"$1\"\n"},{"id":"11179","messageId":"7voe4y5w3v.fsf@assigned-by-dhcp.cox.net","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511051247330.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T02:49:24Z","receivedAt":"2005-11-06T02:49:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever \n> try to use the horrid gnome executable finder on it when you want to \n> convince firefox to use xpdf instead of that broken crap called \"evince\"? \n> Takes absolutely ages and is horrible).\n>\n> And git made it about 4% worse all on its own.\n\nMy pragmatic half agrees with what you said.  /usr/bin should\nnot contain things that are never used by the end user -- things\nlike git-sh-setup, git-fmt-merge-msg, and git-merge-recursive\nshould not be there.  Not having things like git-show-branch and\ngit-update-index in /usr/bin is a regression because it needs an\nextra fork to call them through 'git' wrapper, but I could live\nwith that.\n\nMy purist half, however, says that it is a wrong solution to the\nproblem.  If having many files in /usr/bin hurts performance,\nyou should be using a filesystem that handles large directory\nbetter.  Modern shells already know how to hash command names\nfound in $PATH.  It is just your gnome executable finder that is\nlacking the knowledge of which binaries are appropriate for what\nmimetype; perhaps your distribution could help by having a way\nfor each package to register programs that handle particular\nmimetypes well with the system-wide database.\n\nAnd my lazy remainder (yes, I add up to more then one ;-))\ncheers on my purist side.\n\nBut common sense prevails at the end of the day.  I would not\nfight a battle I know I would not be able to win.  So what\nshould we do about this problem?  And when?\n\nSince we do not have enough clout to have /usr/bin/git/ and ask\nthe users to put that in their PATH like X11 does, we need to\nteach some of our commands that use other git commands to\nprepend /usr/lib/git/ (or /usr/libexec/git) on their PATH while\nthey run.  Although many of the Porcelainish commands include\ngit-sh-setup, git-sh-setup itself is a prime candidate to be\nkicked out of /usr/bin, which means essentially everything needs\nto have that PATH trick.\n\nThis also is a bit inconvenient for our in-source-tree tests.\nWe need to be testing what we just built and are about to\ninstall, not what is already installed, so every script needs to\nstart with something like this:\n\n\t#!/bin/sh\n\t: ${GIT_BIN_DIR=@@GIT_BIN_DIR@@}\n        PATH=\"$GIT_BIN_DIR:$PATH\"\n        git-sh-setup || die \"not a git repository\"\n\t...\n\nand our test will run with GIT_BIN_DIR set to `pwd`/../../ (they\nrun in t/trash and what we just built are found at the toplevel\nof the source).  Also we need to do the same for binaries if they\nfork/exec other git commands.\n\nCommands like upload-pack and receive-pack are directly executed\nfrom the ssh connection, and we need to arrange for them to be\nfound on the PATH of users' non-login shells.  This does not\nnecessarily mean these commands need to stay in /usr/bin, but if\nwe move them outside standard PATH, we would need to teach\n.bash_profile vs .bashrc workaround to all users, which I think\nis the yuckiest part of all of the above.\n"},{"id":"11181","messageId":"Pine.LNX.4.64.0511052013550.3316@g5.osdl.org","threadId":"2360","inReplyTo":"7voe4y5w3v.fsf@assigned-by-dhcp.cox.net","subject":"Re: git binary directory?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-06T04:25:25Z","receivedAt":"2005-11-06T04:25:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 Nov 2005, Junio C Hamano wrote:\n> \n> My purist half, however, says that it is a wrong solution to the\n> problem.  If having many files in /usr/bin hurts performance,\n> you should be using a filesystem that handles large directory\n> better.\n\nI disagree with your arguments, even though I'm not convinced we \nnecessarily need a directory of its own for git.\n\nWe have directories for a reason. You might as well argue that everybody \nshould have a flat namespace, since it should be efficient.\n\nThe performance reason for directories is only secondary. The _real_ \nreason for directories is to keep related things together, and track them \nbetter. Havign a nice directory structure where programs keep their own \nfiles instead of putting them all in the same place is a good thing from \nan organization standpoint.\n\n> Modern shells already know how to hash command names\n> found in $PATH.\n\nRight. And we could add the git directory to the path. In fact, that's \nexactly what the git wrapper script does: this allows the low-level git \nshell scripts to avoid havign to go through the wrapper, since they can \nnow use the native programs directly.\n\n(In fact, that PATH part of the patch is probably a bug-fix regardless: if \nI have two different versions of \"git\", and I ask for the one that isn't \nin my path explicitly, then it should use _its_ git programs, not the \nother versions).\n\n> It is just your gnome executable finder that is\n> lacking the knowledge of which binaries are appropriate for what\n> mimetype;\n\nThe gnome file chooser is horrid, but even in the presense of a _nice_ \nfile manager it's actually not very pleasant to have directories with \nthousands of files. \n\n> Since we do not have enough clout to have /usr/bin/git/ and ask\n> the users to put that in their PATH like X11 does, we need to\n> teach some of our commands that use other git commands to\n> prepend /usr/lib/git/ (or /usr/libexec/git) on their PATH while\n> they run.\n\nDid you miss that part of my patch? That's exactly what this hunk of it \ndoes:\n\n\tdiff --git a/git.sh b/git.sh\n\tindex 94940ae..9ba1608 100755\n\t--- a/git.sh\n\t+++ b/git.sh\n\t@@ -1,7 +1,8 @@\n\t #!/bin/sh\n\t \n\t cmd=\n\t-path=$(dirname \"$0\")\n\t+path=\"@@GITDIR@@\"\n\t+export PATH=\"$path:$PATH\"\n\t case \"$#\" in\n\t 0)\t;;\n\t *)\tcmd=\"$1\"\n\nand as mentioned, I actually think it's a bugfix regardless of anything \nelse (do a \"./git log\", and it will _not_ execute \"./git-rev-parse\" and \n\"./git-rev-list\": it will execute whatever was in the path, usually \n/usr/bin/git-rev-xyzzy).\n\nNow, gitk didn't do that, which is a bug.\n\n> Although many of the Porcelainish commands include\n> git-sh-setup, git-sh-setup itself is a prime candidate to be\n> kicked out of /usr/bin, which means essentially everything needs\n> to have that PATH trick.\n\nYes. All porcelain would need to do the PATH thing, I think.\n\n> This also is a bit inconvenient for our in-source-tree tests.\n> We need to be testing what we just built and are about to\n> install, not what is already installed, so every script needs to\n> start with something like this:\n\nNo, the actual programs and scripts themselves shouldn't change. Nothing \nthat uses git-sh-setup should change, only the programs that are installed \nin /usr/bin would need to know that the helper programs are _not_ there, \nand set up the path properly.\n\nBut if we do that right, that should be just a couple of executables, \nwhich is the whole point of splitting this up.\n\nBut yes, you're right that right now we're not always set up for this, and \ngit-upload-pack etc that execute directly from the shell would need help.\n\n\t\tLinus\n"},{"id":"11183","messageId":"7vy84249re.fsf@assigned-by-dhcp.cox.net","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511052013550.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T05:37:25Z","receivedAt":"2005-11-06T05:37:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> We have directories for a reason. You might as well argue that everybody \n> should have a flat namespace, since it should be efficient.\n>\n> The performance reason for directories is only secondary. The _real_ \n> reason for directories is to keep related things together, and track them \n> better. Havign a nice directory structure where programs keep their own \n> files instead of putting them all in the same place is a good thing from \n> an organization standpoint.\n\nMy point (actually, my purist half's point) is that /usr/bin is\nthat nice structure that keeps related things together --- the\nrelatedness of them being \"the end user would want to run them\".\nYour initial hesitation that the change being discussed would\nforce you to say \"git whatchanged\" when you are so accustomed to\ntype git-whatchanged is valid.  Unfortunately, we have far more\ncommands in /usr/bin than good old V7 days, and while the\n_primary_ purpose of /usr/bin is to hold \"the end user would\nwant to run them\" things together (hence, shell needs to know\nonly about handful places to look at), having thousands of\nthings in one place is inconvenient for purposes other than the\nprimary purpose of that grouping (i.e. running them), such as\nbrowsing them.\n\nYou could deviate from the UNIX tradition and \"keep related\nthings together\" in different ways; you _could_ have\n/usr/bin/pdf-viewers/, /usr/bin/html-viewers/, etc. to hold\nxpdf, acroread, firefox and iexplorer in them if you do not like\n/usr/bin/ that has many executables -- but we do not do that.\n\n> (In fact, that PATH part of the patch is probably a bug-fix regardless: if \n> I have two different versions of \"git\", and I ask for the one that isn't \n> in my path explicitly, then it should use _its_ git programs, not the \n> other versions).\n\nI think that is a valid change.\n\n> The gnome file chooser is horrid, but even in the presense of a _nice_ \n> file manager it's actually not very pleasant to have directories with \n> thousands of files. \n\nYes, but I think we should blame UNIX tradition for that ;-).\n\n> Did you miss that part of my patch?\n\nSorry, my reply was prepared before I actually saw that patch\n(you would notice it was a reply to your first message).  I\nthink what you did in your patch makes sense.  The end users\nshould always say 'git update-index' (or know the lib/git path\nand it they want to say git-update-index), even when running the\nlow-level commands, and as long as they use 'git' wrapper that\napproach would work.\n\n> Yes. All porcelain would need to do the PATH thing, I think.\n\nNo, we could just say 'git commit' and 'git' is the only thing\nthat needs to know the PATH thing, as you did.\n\n> But yes, you're right that right now we're not always set up for this, and \n> git-upload-pack etc that execute directly from the shell would need help.\n\nWe _could_ even invoke 'git upload-pack' from 'git-fetch'.\n"},{"id":"11185","messageId":"7vfyqa44qq.fsf@assigned-by-dhcp.cox.net","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511051625110.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T07:25:49Z","receivedAt":"2005-11-06T07:25:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> This fixes the gitk thing, by installing it (along with git) in the \n> regular $prefix/bin directory (ie default /usr/bin for the RPM).\n\nThe other half of the fix needed to gitk is to teach it to use\n/usr/lib/git-@@VERSION@@ to locate git-rev-list and friends.\n\nI really hate to do this, but here is an attempt on top of your\npatch, which:\n\n - makes gitk also use the @@GITDIR@@ to find git commands;\n\n - makes git and gitk honor $GIT_LIBEXEC environment, to let you\n   override the hardcoded @@GITDIR@@;\n\n - makes \"make clean\" to clean generated file git again.\n\nI am not sure how to handle gitk part, but the best approach\nwould be to sell this change (including the rename) back to\nPaulus the upstream.\n\n---\ndiff --git a/Makefile b/Makefile\nindex 2e78089..1948aa1 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -327,6 +327,15 @@ git: git.sh Makefile\n \tchmod +x $@+\n \tmv $@+ $@\n \n+gitk: gitk.tcl Makefile\n+\trm -f $@+ $@\n+\tsed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \\\n+\t    -e 's:@@GITDIR@@:$(gitdir):g' \\\n+\t    -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \\\n+\t    <$@.tcl >$@+\n+\tchmod +x $@+\n+\tmv $@+ $@\n+\n $(filter-out git,$(patsubst %.sh,%,$(SCRIPT_SH))) : % : %.sh\n \trm -f $@\n \tsed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \\\n@@ -450,7 +459,7 @@ deb: dist\n \n clean:\n \trm -f *.o mozilla-sha1/*.o ppc/*.o compat/*.o $(PROGRAMS) $(LIB_FILE)\n-\trm -f $(SCRIPTS)\n+\trm -f $(SCRIPTS) git gitk\n \trm -f git-core.spec *.pyc *.pyo\n \trm -rf $(GIT_TARNAME)\n \trm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz\ndiff --git a/git.sh b/git.sh\nindex 9ba1608..f39b373 100755\n--- a/git.sh\n+++ b/git.sh\n@@ -1,7 +1,13 @@\n #!/bin/sh\n \n cmd=\n-path=\"@@GITDIR@@\"\n+case \"$GIT_LIBEXEC\" in\n+'')\n+\tGIT_LIBEXEC='@@GITDIR@@'\n+\texport GIT_LIBEXEC\n+\t;;\n+esac\n+path=\"$GIT_LIBEXEC\"\n export PATH=\"$path:$PATH\"\n case \"$#\" in\n 0)\t;;\ndiff --git a/gitk b/gitk.tcl\nsimilarity index 100%\nrename from gitk\nrename to gitk.tcl\nindex a9d37d9..be9a79e 100755\n--- a/gitk\n+++ b/gitk.tcl\n@@ -7,6 +7,11 @@ exec wish \"$0\" -- \"$@\"\n # and distributed under the terms of the GNU General Public Licence,\n # either version 2, or (at your option) any later version.\n \n+if {![info exists env(GIT_LIBEXEC)]} {\n+    set env(GIT_LIBEXEC) \"@@GITDIR@@\"\n+}\n+set env(PATH) \"$env(GIT_LIBEXEC):$env(PATH)\"\n+\n proc gitdir {} {\n     global env\n     if {[info exists env(GIT_DIR)]} {\n"},{"id":"11207","messageId":"Pine.LNX.4.64.0511060816390.3316@g5.osdl.org","threadId":"2360","inReplyTo":"7vy84249re.fsf@assigned-by-dhcp.cox.net","subject":"Re: git binary directory?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-06T16:20:41Z","receivedAt":"2005-11-06T16:20:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 5 Nov 2005, Junio C Hamano wrote:\n> \n> My point (actually, my purist half's point) is that /usr/bin is\n> that nice structure that keeps related things together --- the\n> relatedness of them being \"the end user would want to run them\".\n\nYes. I wish there was some way around that.\n\nRight now, for a 1.0 release, I suspect that the \"put the git binaries \nsomewhere else\" just isn't worth it. It will break existing scripts that \nuse the binaries directly (we've already broken the kernel.org snapshot \nscripts about a million times with just _renaming_ the binaries ;)\n\nIt would still be nice to not screw up peoples /usr/bin too badly. At \nleast we have the nice property that our git programs sort together and \ncan pretty much be wild-carded (not everybody uses package installers, and \non one machine I had just done \"make prefix=/usr install\" and was happy to \nbe able to basically remove it with \"rm /usr/bin/git-*\")\n\n\t\t\tLinus\n"},{"id":"11217","messageId":"7v7jbly1lh.fsf@assigned-by-dhcp.cox.net","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511060816390.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T20:15:38Z","receivedAt":"2005-11-06T20:15:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> Right now, for a 1.0 release, I suspect that the \"put the git binaries \n> somewhere else\" just isn't worth it. It will break existing scripts that \n> use the binaries directly (we've already broken the kernel.org snapshot \n> scripts about a million times with just _renaming_ the binaries ;)\n\nAlthough I _really_ wanted a 1.0 soonish, I personally feel that\nthis change is better done now than later, if we are eventually\ngoing to do it anyway.  \"Never\" _might_ be better than \"now\",\nbut I suspect \"later\" or \"post 1.0\" is worse.\n"},{"id":"11223","messageId":"20051106221952.GP1431@pasky.or.cz","threadId":"2360","inReplyTo":"7v7jbly1lh.fsf@assigned-by-dhcp.cox.net","subject":"Re: git binary directory?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-06T22:19:52Z","receivedAt":"2005-11-06T22:19:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Nov 06, 2005 at 09:15:38PM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > Right now, for a 1.0 release, I suspect that the \"put the git binaries \n> > somewhere else\" just isn't worth it. It will break existing scripts that \n> > use the binaries directly (we've already broken the kernel.org snapshot \n> > scripts about a million times with just _renaming_ the binaries ;)\n> \n> Although I _really_ wanted a 1.0 soonish, I personally feel that\n> this change is better done now than later, if we are eventually\n> going to do it anyway.  \"Never\" _might_ be better than \"now\",\n> but I suspect \"later\" or \"post 1.0\" is worse.\n\nYou are also going to break the porcelains (w/o manual user\nintervention), so I'm not happy about it but if you are doing it, do it\nnow, please. :-)\n\nBTW, can I easily get the patch from the 'git' tool, so that I can\nextend $PATH appropriately during Cogito initialization?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11231","messageId":"7virv5wc86.fsf@assigned-by-dhcp.cox.net","threadId":"2360","inReplyTo":"20051106221952.GP1431@pasky.or.cz","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-07T00:08:57Z","receivedAt":"2005-11-07T00:08:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> You are also going to break the porcelains (w/o manual user\n> intervention), so I'm not happy about it but if you are doing it, do it\n> now, please. :-)\n\nI thought Porcelains and people's script can just say 'git foo'\neverywhere where it currently says 'git-foo', and it should work\nbefore and after the change, and that is what I did to my\nprivate scripts.  But you are right, it is nicer if 'git-foo'\ncontinued to work with a single patch to cg-Xlib or somewhere\ncentral like that.\n\n> BTW, can I easily get the patch from the 'git' tool, so that I can\n> extend $PATH appropriately during Cogito initialization?\n\nDo you mean 'git --show-git-libdir' or something like that?\n"},{"id":"11233","messageId":"20051107004346.GR1431@pasky.or.cz","threadId":"2360","inReplyTo":"7virv5wc86.fsf@assigned-by-dhcp.cox.net","subject":"Re: git binary directory?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-07T00:43:46Z","receivedAt":"2005-11-07T00:43:46Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Nov 07, 2005 at 01:08:57AM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > You are also going to break the porcelains (w/o manual user\n> > intervention), so I'm not happy about it but if you are doing it, do it\n> > now, please. :-)\n> \n> I thought Porcelains and people's script can just say 'git foo'\n> everywhere where it currently says 'git-foo', and it should work\n> before and after the change, and that is what I did to my\n> private scripts.  But you are right, it is nicer if 'git-foo'\n> continued to work with a single patch to cg-Xlib or somewhere\n> central like that.\n\nI want to avoid extra fork()s and exec()s. They seem to routinely matter\nin orders of magnitude of speed in tight loops.\n\nBesides, I'm more used to the dash form. ;-)\n\n> > BTW, can I easily get the patch from the 'git' tool, so that I can\n> > extend $PATH appropriately during Cogito initialization?\n> \n> Do you mean 'git --show-git-libdir' or something like that?\n\nYes. Well... you said you have the gitdir changes in your 'pu' branch,\nbut http://www.kernel.org/git/?p=git/git.git;a=tree;h=pu;hb=pu doesn't\nappear to have the changes...?\n\nIs --show-git-libdir already implemented?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11234","messageId":"Pine.LNX.4.64.0511061653380.3316@g5.osdl.org","threadId":"2360","inReplyTo":"20051107004346.GR1431@pasky.or.cz","subject":"Re: git binary directory?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-07T00:54:55Z","receivedAt":"2005-11-07T00:54:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 7 Nov 2005, Petr Baudis wrote:\n> \n> I want to avoid extra fork()s and exec()s. They seem to routinely matter\n> in orders of magnitude of speed in tight loops.\n\nYes. The more I think about it, the less I like the separate binary \ndirectory after all. The \"git cmd\" format is great for high-level \ncommands, but we've always done \"git-diff-tree\" and \"git-rev-list\" etc \nwithout the \"git cmd\" indirection.\n\nThe downsides of a separate binary directory appear to be bigger than the \nupside..\n\n\t\tLinus\n"},{"id":"11250","messageId":"20051107094555.GS1431@pasky.or.cz","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511061653380.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-07T09:45:55Z","receivedAt":"2005-11-07T09:45:55Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Nov 07, 2005 at 01:54:55AM CET, I got a letter\nwhere Linus Torvalds <torvalds@osdl.org> told me that...\n> On Mon, 7 Nov 2005, Petr Baudis wrote:\n> > \n> > I want to avoid extra fork()s and exec()s. They seem to routinely matter\n> > in orders of magnitude of speed in tight loops.\n> \n> Yes. The more I think about it, the less I like the separate binary \n> directory after all. The \"git cmd\" format is great for high-level \n> commands, but we've always done \"git-diff-tree\" and \"git-rev-list\" etc \n> without the \"git cmd\" indirection.\n> \n> The downsides of a separate binary directory appear to be bigger than the \n> upside..\n\nWell, _one_ fork per user invocation (subsequent invocations wouldn't\nneed it, I already \"cache\" this kind of stuff in the environment) of a\nCogito command (to get the path to the gitdir) is not such a big deal,\nI think.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11264","messageId":"7vvez4s6zv.fsf@assigned-by-dhcp.cox.net","threadId":"2360","inReplyTo":"Pine.LNX.4.64.0511061653380.3316@g5.osdl.org","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-07T17:27:48Z","receivedAt":"2005-11-07T17:27:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Mon, 7 Nov 2005, Petr Baudis wrote:\n>> \n>> I want to avoid extra fork()s and exec()s. They seem to routinely matter\n>> in orders of magnitude of speed in tight loops.\n>\n> Yes. The more I think about it, the less I like the separate binary \n> directory after all. The \"git cmd\" format is great for high-level \n> commands, but we've always done \"git-diff-tree\" and \"git-rev-list\" etc \n> without the \"git cmd\" indirection.\n\nExtra fork() and exec() problem still exists, but \"git cmd\"\nformat have worked with \"git diff-tree\" and \"git rev-list\" for\nquite some time (since Jun 14th), so you might've always done it\nwith dash but that is not a requirement.\n\nIt looks like that both you and Pasky are not so enthusiastic\nabout moving thing out of /usr/bin/, so let's keep things the\nway they are for 1.0 release and rethink when we do 2.0 (or\nwhatever comes after 1.0).\n"},{"id":"11390","messageId":"4371FA74.5070504@op5.se","threadId":"2360","inReplyTo":"20051107004346.GR1431@pasky.or.cz","subject":"Re: git binary directory?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-09T13:32:36Z","receivedAt":"2005-11-09T13:32:36Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Petr Baudis wrote:\n> \n> I want to avoid extra fork()s and exec()s. They seem to routinely matter\n> in orders of magnitude of speed in tight loops.\n> \n\nGive this a whirl. It's still slower than using the git-<something> \nform, but it's quite an improvement anyways.\n\n#############\n\n$ time for i in `seq 1 10000`; do git send-pack --help >/dev/null 2>&1; done\n\nreal    0m28.921s\nuser    0m12.626s\nsys     0m14.219s\n$ time for i in `seq 1 10000`; do ./git send-pack --help >/dev/null \n2>&1; done\n\nreal    0m12.129s\nuser    0m4.444s\nsys     0m7.615s\n$ time for i in `seq 1 10000`; do git-send-pack --help >/dev/null 2>&1; done\n\nreal    0m9.069s\nuser    0m3.481s\nsys     0m5.558s\n\n##############\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\n\n#include <stdio.h>\n#include <unistd.h>\n#include <stdlib.h>\n#include <string.h>\n#include <errno.h>\n#include <limits.h>\n#include <stdarg.h>\n#include <glob.h>\n\n#ifndef PATH_MAX\n# define PATH_MAX 4096\n#endif\n\nstatic const char git_usage[] =\n\t\"Usage: git [ --version ] [ --lib=<GIT_LIB> ] COMMAND [ OPTIONS ] [ TARGET ]\";\n\nstruct string_list {\n\tsize_t len;\n\tchar *str;\n\tstruct string_list *next;\n};\n\n/* most gui terms set COLUMNS (although some don't export it) */\nstatic int columns(void)\n{\n\tchar *col_string = getenv(\"COLUMNS\");\n\tint n_cols = 0;\n\n\tif (col_string && (n_cols = atoi(col_string)) > 0)\n\t\treturn n_cols;\n\n\treturn 80;\n}\n\nstatic inline void mput_char(char c, unsigned int num)\n{\n\tunsigned int i;\n\n\tfor(i = 0; i < num; i++)\n\t\tputchar(c);\n}\n\nstatic void fmt_print_string_list(struct string_list *list, int longest)\n{\n\tint cols;\n\tint space = longest + 1; /* space between start of string1 and string2 */\n\tint max_cols = columns() - 1;\n\n\tcols = max_cols / space;\n\n\tif(cols < 1) {\n\t\tcols = 1;\n\t\tspace = 0;\n\t}\n\n\twhile (list) {\n\t\tint c = cols;\n\t\tprintf(\"  \");\n\n\t\tfor(c = cols; c; c--) {\n\t\t\tif (!list)\n\t\t\t\tbreak;\n\n\t\t\tprintf(\"%s\", list->str);\n\n\t\t\tif (space && c != 1)\n\t\t\t\tmput_char(' ', space - list->len);\n\n\t\t\tlist = list->next;\n\t\t}\n\n\t\tputchar('\\n');\n\t}\n}\n\nstatic void usage(char *path, const char *fmt, ...)\n\t__attribute__((__format__(__printf__, 2, 3)));\n\nstatic void usage(char *path, const char *fmt, ...)\n{\n\tstruct string_list *list, *tail;\n\tunsigned int longest = 0, i;\n\tglob_t gl;\n\n\tlist = tail = NULL;\n\n\tif (!fmt)\n\t\tputs(git_usage);\n\telse {\n\t\tprintf(\"git: \");\n\t\tva_list ap;\n\t\tva_start(ap, fmt);\n\t\tvprintf(fmt, ap);\n\t\tva_end(ap);\n\t}\n\n\tputchar('\\n');\n\n\tif (!path)\n\t\texit(1);\n\n\tif (chdir(path) < 0) {\n\t\tprintf(\"git: '%s': %s\\n\", path, strerror(errno));\n\t\texit(1);\n\t}\n\n\tprintf(\"\\ngit commands available in '%s'\\n\", path);\n\tprintf(\"----------------------------\");\n\tmput_char('-', strlen(path));\n\tputchar('\\n');\n\n\tglob(\"git-*\", 0, NULL, &gl);\n\tfor (i = 0; i < gl.gl_pathc; i++) {\n\t\tint len = strlen(gl.gl_pathv[i] + 4);\n\n\t\tif(access(gl.gl_pathv[i], X_OK))\n\t\t\tcontinue;\n\n\t\tif (longest < len)\n\t\t\tlongest = len;\n\n\t\tif (!tail)\n\t\t\ttail = list = malloc(sizeof(struct string_list));\n\t\telse {\n\t\t\ttail->next = malloc(sizeof(struct string_list));\n\t\t\ttail = tail->next;\n\t\t}\n\t\ttail->len = len;\n\t\ttail->str = gl.gl_pathv[i] + 4;\n\t\ttail->next = NULL;\n\t}\n\n\tfmt_print_string_list(list, longest);\n\n\tputs(\"\\nman-pages can be reached through 'man git-<COMMAND>'\\n\");\n\n\texit(1);\n}\n\n#define DEFAULT_GIT_LIB \"/usr/bin\"\n#define GIT_VERSION \"0.99.9.GIT\"\n\nint main(int argc, char **argv, char **envp)\n{\n\tchar git_command[PATH_MAX + 1];\n\tchar *git_lib = getenv(\"GIT_LIB\");\n\tchar wd[PATH_MAX + 1], libdir[PATH_MAX + 1];\n\n\tgetcwd(wd, PATH_MAX);\n\n\tif(argc == 1) {\n\t\tif (git_lib)\n\t\t\tusage(git_lib, NULL);\n\n\t\tusage(DEFAULT_GIT_LIB, NULL);\n\t}\n\n\targv++;\n\t/* always *argv since we inc it if we hit an option */\n\twhile (argc-- && !strncmp(*argv, \"--\", 2)) {\n\t\tchar *arg = (*argv++) + 2;\n\n\t\tif (!strncmp(arg, \"lib=\", 3))\n\t\t\tgit_lib = arg + 4;\n\t\telse if (!strncmp(arg, \"version\", 7)) {\n\t\t\tprintf(\"git version %s\\n\", GIT_VERSION);\n\t\t\texit(0);\n\t\t}\n\t\telse\n\t\t\tusage (NULL, NULL);\n\t}\n\n\tif (!git_lib)\n\t\tgit_lib = DEFAULT_GIT_LIB;\n\n\t/* allow relative paths, but run with exact */\n\tif (chdir(git_lib)) {\n\t\tprintf(\"git: '%s': %s\\n\", git_lib, strerror(errno));\n\t\texit (1);\n\t}\n\n\tgetcwd(libdir, sizeof(libdir));\n\tchdir(wd);\n\n\tsnprintf(git_command, sizeof(git_command), \"%s/git-%s\", libdir, *argv);\n\n\tif (access(git_command, X_OK))\n\t\tusage(git_lib, \"'%s' is not a git-command\", *argv);\n\n\tif (execve(git_command, argv, envp)) {\n\t\tprintf(\"Failed to run command '%s': %s\\n\", git_command, strerror(errno));\n\t\treturn 1;\n\t}\n\n\t/* not reached */\n\n\treturn 0;\n}\n"},{"id":"11465","messageId":"20051110094931.GO30496@pasky.or.cz","threadId":"2360","inReplyTo":"7vvez4s6zv.fsf@assigned-by-dhcp.cox.net","subject":"Re: git binary directory?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-10T09:49:31Z","receivedAt":"2005-11-10T09:49:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Nov 07, 2005 at 06:27:48PM CET, I got a letter\nwhere Junio C Hamano <junkio@cox.net> said that...\n> It looks like that both you and Pasky are not so enthusiastic\n> about moving thing out of /usr/bin/, so let's keep things the\n> way they are for 1.0 release and rethink when we do 2.0 (or\n> whatever comes after 1.0).\n\nWell, just to clarify - I'm personally not opposed to it, as long as it\ngets done in some timeframe where it won't drastically break backwards\ncompatibility (that is, not in 1.0.1 or such, but e.g. at some right\nmoment before 1.0 or at the start of the next development series\nwhenever that happens), and as long as I get a way to get the path\nof the git commands by a single fork().\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"}]}