{"thread":{"id":"11033","subject":"[PATCH RFC] Move all dashed form git commands to libexecdir","startedAt":"2007-11-27T15:02:29Z","lastAt":"2007-12-02T17:23:52Z","messageCount":92,"participants":["Nguyễn Thái Ngọc Duy","Johannes Schindelin","Nicolas Pitre","Nguyễn Thái Ngoc Duy","Jan Hudec","Junio C Hamano","Nguyen Thai Ngoc Duy","Jakub Narebski","A Large Angry SCM","Jeff King","Linus Torvalds","Steffen Prohaska","Andreas Ericsson","Wincent Colaiuta","Eyvind Bernhardsen","Santi Béjar","Pascal Obry"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"61084","messageId":"20071127150229.GA14859@laptop","threadId":"11033","inReplyTo":null,"subject":"[PATCH RFC] Move all dashed form git commands to libexecdir","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-27T15:02:29Z","receivedAt":"2007-11-27T15:02:29Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n We have talked about it for quite some time now. How about\n making it happen? I won't miss dashed form commands much :)\n\n A compromised approach could be keeping porcelain commands\n in bindir, only plumbings are moved to libexecdir. That would\n be less shock than this.\n\n config.mak.in | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/config.mak.in b/config.mak.in\nindex 11d256e..1db0338 100644\n--- a/config.mak.in\n+++ b/config.mak.in\n@@ -11,7 +11,7 @@ TCLTK_PATH = @TCLTK_PATH@\n prefix = @prefix@\n exec_prefix = @exec_prefix@\n bindir = @bindir@\n-#gitexecdir = @libexecdir@/git-core/\n+gitexecdir = @libexecdir@/git-core/\n datarootdir = @datarootdir@\n template_dir = @datadir@/git-core/templates/\n \n-- \n1.5.3.GIT\n"},{"id":"61087","messageId":"Pine.LNX.4.64.0711271511091.27959@racer.site","threadId":"11033","inReplyTo":"20071127150229.GA14859@laptop","subject":"Re: [PATCH RFC] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T15:12:48Z","receivedAt":"2007-11-27T15:12:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Nguyễn Thái Ngọc Duy wrote:\n\n> diff --git a/config.mak.in b/config.mak.in\n\nI don't use configure, and don't expect distros to use it either. Maybe \nyou want to change Makefile first, so that the hard-core \"next\" followers \ntest it first? Then, when everything is worked out and deemed to be \nstable, Junio can merge it to \"master\", and we can adjust the rpm spec and \nbug packagers to change their setup?\n\nCiao,\nDscho"},{"id":"61092","messageId":"alpine.LFD.0.99999.0711271024460.9605@xanadu.home","threadId":"11033","inReplyTo":"20071127150229.GA14859@laptop","subject":"Re: [PATCH RFC] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-27T15:25:33Z","receivedAt":"2007-11-27T15:25:33Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Nov 2007, Nguyễn Thái Ngọc Duy wrote:\n\n> We have talked about it for quite some time now. How about\n> making it happen? I won't miss dashed form commands much :)\n> \n> A compromised approach could be keeping porcelain commands\n> in bindir, only plumbings are moved to libexecdir. That would\n> be less shock than this.\n\nI think that would be an excellent idea.\n\n\nNicolas\n"},{"id":"61095","messageId":"20071127160423.GA22807@laptop","threadId":"11033","inReplyTo":"20071127150229.GA14859@laptop","subject":"[PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyễn Thái Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-27T16:04:23Z","receivedAt":"2007-11-27T16:04:23Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Both configure and make-only ways should work now\n\n Makefile | 2 +-\n config.mak.in | 2 +-\n 2 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 313f9a2..377d7be 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -154,7 +154,7 @@ STRIP ?= strip\n \n prefix = $(HOME)\n bindir = $(prefix)/bin\n-gitexecdir = $(bindir)\n+gitexecdir = $(prefix)/libexec/git-core\n sharedir = $(prefix)/share\n template_dir = $(sharedir)/git-core/templates\n ifeq ($(prefix),/usr)\ndiff --git a/config.mak.in b/config.mak.in\nindex 11d256e..1db0338 100644\n--- a/config.mak.in\n+++ b/config.mak.in\n@@ -11,7 +11,7 @@ TCLTK_PATH = @TCLTK_PATH@\n prefix = @prefix@\n exec_prefix = @exec_prefix@\n bindir = @bindir@\n-#gitexecdir = @libexecdir@/git-core/\n+gitexecdir = @libexecdir@/git-core/\n datarootdir = @datarootdir@\n template_dir = @datadir@/git-core/templates/\n \n-- \n1.5.3.GIT\n"},{"id":"61097","messageId":"Pine.LNX.4.64.0711271617350.27959@racer.site","threadId":"11033","inReplyTo":"20071127160423.GA22807@laptop","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-27T16:18:01Z","receivedAt":"2007-11-27T16:18:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:\n\n> Both configure and make-only ways should work now\n\nI thought your plan was to put the non-porcelain into the libexecdir only?\n\nCiao,\nDscho"},{"id":"61139","messageId":"20071128000731.GD9174@efreet.light.src","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711271617350.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-28T00:07:31Z","receivedAt":"2007-11-28T00:07:31Z","isPatch":true,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:\n> \n> > Both configure and make-only ways should work now\n> \n> I thought your plan was to put the non-porcelain into the libexecdir only?\n\nI had the impression that deprecating the dash notation for /all/ use was\napproved some time ago. Though I don't want to search through the list\narchives this late in the night to check it.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"61143","messageId":"7v8x4jb295.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"20071128000731.GD9174@efreet.light.src","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T01:13:58Z","receivedAt":"2007-11-28T01:13:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jan Hudec writes:\n\n> On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:\n>> Hi,\n>> \n>> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:\n>> \n>> > Both configure and make-only ways should work now\n>> \n>> I thought your plan was to put the non-porcelain into the libexecdir only?\n>\n> I had the impression that deprecating the dash notation for /all/ use was\n> approved some time ago. Though I don't want to search through the list\n> archives this late in the night to check it.\n\nYes. Moving the dash-form commands out of end user's PATH was something\ndistros and users have been allowed to do since forever, and strictly\nspeaking, using dash form from the command line was already deprecated\nat that point.\n\nIf your script runs git-foo without first asking \"git --exec-path\" and\nprepending it to the path, your script would not find git-foo if the\ninstallation uses gitexecdir that is not on the usual $PATH, either.\n\nI essentially just said that your patch is unnecessary, but at the same\ntime, your patch does not go far enough. As Nico earlier pointed out,\nwe ship a sample rpm spec, which would also need to be updated. We do\nnot ship a sample debian/rules anymore, thank $DEITY ;-)\n\nAlso, because we do not remove existing files from the installation\ntarget directory when we do \"make install\", the commit log message\nshould carry a big fat warning that says \"remove old installation of git\nfrom your $(bindir) when you try this,\" for people who build from the\nsource, and we need to repeat the deprecation notice in bold red letters\nin the Release Notes for perhaps git 1.6.0.\n\nIn case somebody is thinking about 36e5e70e0f40 (Start deprecating\n\"git-command\" in favor of \"git command\"), that is a somewhat different\nissue. What Linus suggested is not installing git-foo link for built-in\ncommands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\nThat is not deprecating dash form but removing the support for it. We\nneed to give ample time for users to adjust to such a change.\n"},{"id":"61189","messageId":"20071128081818.GA16825@efreet.light.src","threadId":"11033","inReplyTo":"7v8x4jb295.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-11-28T08:18:18Z","receivedAt":"2007-11-28T08:18:18Z","isPatch":true,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Nov 27, 2007 at 17:13:58 -0800, Junio C Hamano wrote:\n> Jan Hudec writes:\n> > On Tue, Nov 27, 2007 at 16:18:01 +0000, Johannes Schindelin wrote:\n> >> On Tue, 27 Nov 2007, Nguyễn Thái Ngoc Duy wrote:\n> >> \n> >> > Both configure and make-only ways should work now\n> >> \n> >> I thought your plan was to put the non-porcelain into the libexecdir only?\n> >\n> > I had the impression that deprecating the dash notation for /all/ use was\n> > approved some time ago. Though I don't want to search through the list\n> > archives this late in the night to check it.\n> \n> [...]\n>\n> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n> \"git-command\" in favor of \"git command\"), that is a somewhat different\n> issue. What Linus suggested is not installing git-foo link for built-in\n> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n> That is not deprecating dash form but removing the support for it. We\n> need to give ample time for users to adjust to such a change.\n\nYes, that is what I said I recall seeing. Installing out of user's PATH is\na step towards not installing at all and the change suggests it has been\nalready accepted as a general direction for future. Or not?\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"61192","messageId":"fcaeb9bf0711280036p33583824ge59af93bbe3f0a78@mail.gmail.com","threadId":"11033","inReplyTo":"7v8x4jb295.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-28T08:36:23Z","receivedAt":"2007-11-28T08:36:23Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 28, 2007 8:13 AM, Junio C Hamano wrote:\n> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n> \"git-command\" in favor of \"git command\"), that is a somewhat different\n> issue. What Linus suggested is not installing git-foo link for built-in\n> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n> That is not deprecating dash form but removing the support for it. We\n> need to give ample time for users to adjust to such a change.\n\nA little note on this one. I've been using git without builtin links\nfor a while with my git-box port. There are still some builtin fixups\nneeded. And because execv_git_cmd() always uses dash form, so it's\nimpossible to use vanilla git without builtin links.\n-- \nDuy\n"},{"id":"61322","messageId":"7vfxyq2c9b.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"fcaeb9bf0711280036p33583824ge59af93bbe3f0a78@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T23:14:56Z","receivedAt":"2007-11-28T23:14:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On Nov 28, 2007 8:13 AM, Junio C Hamano wrote:\n>> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n>> \"git-command\" in favor of \"git command\"), that is a somewhat different\n>> issue. What Linus suggested is not installing git-foo link for built-in\n>> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n>> That is not deprecating dash form but removing the support for it. We\n>> need to give ample time for users to adjust to such a change.\n>\n> A little note on this one. I've been using git without builtin links\n> for a while with my git-box port. There are still some builtin fixups\n> needed. And because execv_git_cmd() always uses dash form, so it's\n> impossible to use vanilla git without builtin links.\n\nThanks for a heads up.\n\nWould people agree with a rough roadmap like this?\n\n - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n release notes for the version will warn users that:\n\n (1) using git-foo from the command line, and\n\n (2) using git-foo from your scripts without first prepending the\n return value of \"git --exec-path\" to the PATH\n\n is now officially deprecated (it has been deprecated for a long time\n since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n the default configuration that does not install git-foo form in\n user's PATH.\n\n - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.\n\n - The release notes for v1.5.5 will warn users that git-foo will be\n removed in v1.6.0 for many commands and it will be merely an accident\n if some of them still work.\n\n - Post v1.5.5, start cooking the change that does not install hardlinks\n for built-in commands, aiming for inclusion in v1.6.0, by the end of\n 2008.\n"},{"id":"61325","messageId":"Pine.LNX.4.64.0711282334250.27959@racer.site","threadId":"11033","inReplyTo":"7vfxyq2c9b.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-28T23:40:07Z","receivedAt":"2007-11-28T23:40:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> \"Nguyen Thai Ngoc Duy\" writes:\n> \n> > On Nov 28, 2007 8:13 AM, Junio C Hamano wrote:\n> >> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n> >> \"git-command\" in favor of \"git command\"), that is a somewhat different\n> >> issue. What Linus suggested is not installing git-foo link for built-in\n> >> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n> >> That is not deprecating dash form but removing the support for it. We\n> >> need to give ample time for users to adjust to such a change.\n> >\n> > A little note on this one. I've been using git without builtin links\n> > for a while with my git-box port. There are still some builtin fixups\n> > needed. And because execv_git_cmd() always uses dash form, so it's\n> > impossible to use vanilla git without builtin links.\n> \n> Thanks for a heads up.\n> \n> Would people agree with a rough roadmap like this?\n> \n> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n> release notes for the version will warn users that:\n> \n> (1) using git-foo from the command line, and\n> \n> (2) using git-foo from your scripts without first prepending the\n> return value of \"git --exec-path\" to the PATH\n> \n> is now officially deprecated (it has been deprecated for a long time\n> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n> the default configuration that does not install git-foo form in\n> user's PATH.\n\nMaybe we can squeeze a step in here where only porcelains are installed in \nthe bindir?\n\nFWIW I think that we should fix the problem with the builtins being called \nvia their hard links. But how? As of now, libgit.a has no idea what the \nbuiltins are; this information is buried in git.c.\n\nThe fundamental problem is that we cannot move handle_internal_command() \ninto libgit.a, because it has pointers to all builtin cmd_*() functions.\n\nSo maybe the best solution would be to try \"git \" first, and then \n\"git-\"? But this means another exec() call :-(\n\nCiao,\nDscho\n"},{"id":"61329","messageId":"7vr6ia0w4i.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711282334250.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-28T23:48:45Z","receivedAt":"2007-11-28T23:48:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The fundamental problem is that we cannot move handle_internal_command() \n> into libgit.a, because it has pointers to all builtin cmd_*() functions.\n\nWhat's wrong with having cmd_* functions in the library to begin with?\n"},{"id":"61333","messageId":"Pine.LNX.4.64.0711290000430.27959@racer.site","threadId":"11033","inReplyTo":"7vr6ia0w4i.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-29T00:01:26Z","receivedAt":"2007-11-29T00:01:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 28 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > The fundamental problem is that we cannot move \n> > handle_internal_command() into libgit.a, because it has pointers to \n> > all builtin cmd_*() functions.\n> \n> What's wrong with having cmd_* functions in the library to begin with?\n\nI was considering it not desirable (after all, the library is meant to \nhave common functions in it), but you're right...\n\nCiao,\nDscho\n"},{"id":"61335","messageId":"fil08l$u1n$1@ger.gmane.org","threadId":"11033","inReplyTo":"fcaeb9bf0711280036p33583824ge59af93bbe3f0a78@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-11-29T00:14:16Z","receivedAt":"2007-11-29T00:14:16Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> On Nov 28, 2007 8:13 AM, Junio C Hamano wrote:\n>> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n>> \"git-command\" in favor of \"git command\"), that is a somewhat different\n>> issue. What Linus suggested is not installing git-foo link for built-in\n>> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n>> That is not deprecating dash form but removing the support for it. We\n>> need to give ample time for users to adjust to such a change.\n> \n> A little note on this one. I've been using git without builtin links\n> for a while with my git-box port. There are still some builtin fixups\n> needed. And because execv_git_cmd() always uses dash form, so it's\n> impossible to use vanilla git without builtin links.\n\nBy the way, what is the status of your git-box port?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"61343","messageId":"474E0EE6.6070107@gmail.com","threadId":"11033","inReplyTo":"7vfxyq2c9b.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2007-11-29T00:59:18Z","receivedAt":"2007-11-29T00:59:18Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n[...]\n> Would people agree with a rough roadmap like this?\n> \n> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n> release notes for the version will warn users that:\n> \n> (1) using git-foo from the command line, and\n> \n> (2) using git-foo from your scripts without first prepending the\n> return value of \"git --exec-path\" to the PATH\n> \n> is now officially deprecated (it has been deprecated for a long time\n> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n> the default configuration that does not install git-foo form in\n> user's PATH.\n> \n> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n> for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.\n> \n> - The release notes for v1.5.5 will warn users that git-foo will be\n> removed in v1.6.0 for many commands and it will be merely an accident\n> if some of them still work.\n> \n> - Post v1.5.5, start cooking the change that does not install hardlinks\n> for built-in commands, aiming for inclusion in v1.6.0, by the end of\n> 2008.\n\nSo long as there remains the option in the Makefile to install the \n\"dashed\" commands in $(bindir) for those of us that wish it.\n"},{"id":"61346","messageId":"7vfxypzwvx.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"474E0EE6.6070107@gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-29T01:02:58Z","receivedAt":"2007-11-29T01:02:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"A Large Angry SCM writes:\n\n> Junio C Hamano wrote:\n> [...]\n>> Would people agree with a rough roadmap like this?\n>>\n>> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n>> release notes for the version will warn users that:\n>>\n>> (1) using git-foo from the command line, and\n>>\n>> (2) using git-foo from your scripts without first prepending the\n>> return value of \"git --exec-path\" to the PATH\n>>\n>> is now officially deprecated (it has been deprecated for a long time\n>> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n>> the default configuration that does not install git-foo form in\n>> user's PATH.\n>>\n>> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n>> for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.\n>>\n>> - The release notes for v1.5.5 will warn users that git-foo will be\n>> removed in v1.6.0 for many commands and it will be merely an accident\n>> if some of them still work.\n>>\n>> - Post v1.5.5, start cooking the change that does not install hardlinks\n>> for built-in commands, aiming for inclusion in v1.6.0, by the end of\n>> 2008.\n>\n> So long as there remains the option in the Makefile to install the\n> \"dashed\" commands in $(bindir) for those of us that wish it.\n\nSurely.\n\nActually they already have that option of going dashless themselves, so\nin a sense it is not strictly necessary to make a big deal out of this.\n"},{"id":"61358","messageId":"fcaeb9bf0711281917p56cc4228m6c401286439e2a34@mail.gmail.com","threadId":"11033","inReplyTo":"7vfxyq2c9b.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-29T03:17:17Z","receivedAt":"2007-11-29T03:17:17Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 29, 2007 6:14 AM, Junio C Hamano wrote:\n>\n> \"Nguyen Thai Ngoc Duy\" writes:\n>\n> > On Nov 28, 2007 8:13 AM, Junio C Hamano wrote:\n> >> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n> >> \"git-command\" in favor of \"git command\"), that is a somewhat different\n> >> issue. What Linus suggested is not installing git-foo link for built-in\n> >> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n> >> That is not deprecating dash form but removing the support for it. We\n> >> need to give ample time for users to adjust to such a change.\n> >\n> > A little note on this one. I've been using git without builtin links\n> > for a while with my git-box port. There are still some builtin fixups\n> > needed. And because execv_git_cmd() always uses dash form, so it's\n> > impossible to use vanilla git without builtin links.\n>\n> Thanks for a heads up.\n>\n> Would people agree with a rough roadmap like this?\n>\n> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n> release notes for the version will warn users that:\n>\n> (1) using git-foo from the command line, and\n>\n> (2) using git-foo from your scripts without first prepending the\n> return value of \"git --exec-path\" to the PATH\n>\n> is now officially deprecated (it has been deprecated for a long time\n> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n> the default configuration that does not install git-foo form in\n> user's PATH.\n>\n> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n> for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.\n>\n> - The release notes for v1.5.5 will warn users that git-foo will be\n> removed in v1.6.0 for many commands and it will be merely an accident\n> if some of them still work.\n>\n> - Post v1.5.5, start cooking the change that does not install hardlinks\n> for built-in commands, aiming for inclusion in v1.6.0, by the end of\n> 2008.\n\nThere won't be a stage when only porcelain git-foos are in $(bindir)?\nI could stop working on the relevant patch then.\n-- \nDuy\n"},{"id":"61395","messageId":"alpine.LFD.0.99999.0711290905510.9605@xanadu.home","threadId":"11033","inReplyTo":"fcaeb9bf0711281917p56cc4228m6c401286439e2a34@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-29T14:09:42Z","receivedAt":"2007-11-29T14:09:42Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On Nov 29, 2007 6:14 AM, Junio C Hamano wrote:\n> >\n> > \"Nguyen Thai Ngoc Duy\" writes:\n> >\n> > > On Nov 28, 2007 8:13 AM, Junio C Hamano wrote:\n> > >> In case somebody is thinking about 36e5e70e0f40 (Start deprecating\n> > >> \"git-command\" in favor of \"git command\"), that is a somewhat different\n> > >> issue. What Linus suggested is not installing git-foo link for built-in\n> > >> commands _anywhere_ on the filesystem. Not just \"out of user's PATH\".\n> > >> That is not deprecating dash form but removing the support for it. We\n> > >> need to give ample time for users to adjust to such a change.\n> > >\n> > > A little note on this one. I've been using git without builtin links\n> > > for a while with my git-box port. There are still some builtin fixups\n> > > needed. And because execv_git_cmd() always uses dash form, so it's\n> > > impossible to use vanilla git without builtin links.\n> >\n> > Thanks for a heads up.\n> >\n> > Would people agree with a rough roadmap like this?\n> >\n> > - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n> > release notes for the version will warn users that:\n> >\n> > (1) using git-foo from the command line, and\n> >\n> > (2) using git-foo from your scripts without first prepending the\n> > return value of \"git --exec-path\" to the PATH\n> >\n> > is now officially deprecated (it has been deprecated for a long time\n> > since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n> > the default configuration that does not install git-foo form in\n> > user's PATH.\n> >\n> > - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n> > for inclusion in v1.5.5, perhaps in Mar-Feb 2008 timeframe.\n> >\n> > - The release notes for v1.5.5 will warn users that git-foo will be\n> > removed in v1.6.0 for many commands and it will be merely an accident\n> > if some of them still work.\n> >\n> > - Post v1.5.5, start cooking the change that does not install hardlinks\n> > for built-in commands, aiming for inclusion in v1.6.0, by the end of\n> > 2008.\n> \n> There won't be a stage when only porcelain git-foos are in $(bindir)?\n> I could stop working on the relevant patch then.\n\nWell, I personally found your effort really nice. I think Junio is \noverly cautious in this case, and I would prefer to see the number of \ngit commands in the default path drop rather sooner than later.\n\n\nNicolas\n"},{"id":"61401","messageId":"20071129150849.GA32296@coredump.intra.peff.net","threadId":"11033","inReplyTo":"7vfxyq2c9b.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-29T15:08:49Z","receivedAt":"2007-11-29T15:08:49Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Nov 28, 2007 at 03:14:56PM -0800, Junio C Hamano wrote:\n\n> - Post v1.5.5, start cooking the change that does not install hardlinks\n> for built-in commands, aiming for inclusion in v1.6.0, by the end of\n> 2008.\n\nI am against this, unless it is configurable. I think the goal of\nreducing user-visible commands is fine, and moving things to\n$(libexecdir) is a good way of doing that.\n\nHowever, I personally still think the 'git-foo' forms are valuable\n(because fingers have already been trained, and because\nnon-bash-programmable completions understand them). And I don't mind\nputting $(libexecdir)/git-core in my PATH to retain this behavior; it's\na one-time configuration tweak, and it helps new users with the\noverwhelming command set.\n\nBut I don't see a point to removing the links entirely. The annoyance\nfactor for people who want git-* is much higher, and I don't see that it\nactually buys us any help for new users (who will no longer care after\neverything is hidden in $(libexecdir) anyway).\n\n-Peff\n"},{"id":"61419","messageId":"fcaeb9bf0711291205h125dadbbp8e8ae392e9b5b751@mail.gmail.com","threadId":"11033","inReplyTo":"20071129150849.GA32296@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-29T20:05:05Z","receivedAt":"2007-11-29T20:05:05Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 29, 2007 10:08 PM, Jeff King wrote:\n> On Wed, Nov 28, 2007 at 03:14:56PM -0800, Junio C Hamano wrote:\n>\n> > - Post v1.5.5, start cooking the change that does not install hardlinks\n> > for built-in commands, aiming for inclusion in v1.6.0, by the end of\n> > 2008.\n>\n> I am against this, unless it is configurable. I think the goal of\n> reducing user-visible commands is fine, and moving things to\n> $(libexecdir) is a good way of doing that.\n>\n> However, I personally still think the 'git-foo' forms are valuable\n> (because fingers have already been trained, and because\n> non-bash-programmable completions understand them). And I don't mind\n> putting $(libexecdir)/git-core in my PATH to retain this behavior; it's\n> a one-time configuration tweak, and it helps new users with the\n> overwhelming command set.\n>\n> But I don't see a point to removing the links entirely. The annoyance\n> factor for people who want git-* is much higher, and I don't see that it\n> actually buys us any help for new users (who will no longer care after\n> everything is hidden in $(libexecdir) anyway).\n\nMaybe only not install hardlinks on systems that do not support it\nlike Windows? git.exe duplication takes a lot of space.\n-- \nDuy\n"},{"id":"61425","messageId":"20071129211409.GA16625@sigill.intra.peff.net","threadId":"11033","inReplyTo":"fcaeb9bf0711291205h125dadbbp8e8ae392e9b5b751@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-29T21:14:10Z","receivedAt":"2007-11-29T21:14:10Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 03:05:05AM +0700, Nguyen Thai Ngoc Duy wrote:\n\n> > But I don't see a point to removing the links entirely. The annoyance\n> > factor for people who want git-* is much higher, and I don't see that it\n> > actually buys us any help for new users (who will no longer care after\n> > everything is hidden in $(libexecdir) anyway).\n> \n> Maybe only not install hardlinks on systems that do not support it\n> like Windows? git.exe duplication takes a lot of space.\n\nI think that is totally reasonable, as on those platforms there is\nactually something to be gained from removing those hardlinks (you could\nalso of course make a very thin wrapper for \"git-foo\" that called \"git\nfoo\"; it would still be wasteful, but not as much as copying the whole\ngit.exe. But that is not worth doing unless people on Windows really\nwant the dash forms).\n\n-Peff\n"},{"id":"61428","messageId":"Pine.LNX.4.64.0711292218240.27959@racer.site","threadId":"11033","inReplyTo":"20071129211409.GA16625@sigill.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-29T22:19:16Z","receivedAt":"2007-11-29T22:19:16Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Nov 2007, Jeff King wrote:\n\n> On Fri, Nov 30, 2007 at 03:05:05AM +0700, Nguyen Thai Ngoc Duy wrote:\n> \n> > > But I don't see a point to removing the links entirely. The annoyance\n> > > factor for people who want git-* is much higher, and I don't see that it\n> > > actually buys us any help for new users (who will no longer care after\n> > > everything is hidden in $(libexecdir) anyway).\n> > \n> > Maybe only not install hardlinks on systems that do not support it\n> > like Windows? git.exe duplication takes a lot of space.\n> \n> I think that is totally reasonable, as on those platforms there is\n> actually something to be gained from removing those hardlinks (you could\n> also of course make a very thin wrapper for \"git-foo\" that called \"git\n> foo\"; it would still be wasteful, but not as much as copying the whole\n> git.exe. But that is not worth doing unless people on Windows really\n> want the dash forms).\n\nNote that one big problem with a few platforms having dash forms and \nothers not is that you _will_ get scripts and aliases that do not work \neverywhere.\n\nConsistency is good.\n\nCiao,\nDscho\n"},{"id":"61429","messageId":"7vd4tsvfvk.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"alpine.LFD.0.99999.0711290905510.9605@xanadu.home","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-29T22:36:15Z","receivedAt":"2007-11-29T22:36:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Thu, 29 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n>\n>> There won't be a stage when only porcelain git-foos are in $(bindir)?\n>> I could stop working on the relevant patch then.\n>\n> Well, I personally found your effort really nice. I think Junio is \n> overly cautious in this case, and I would prefer to see the number of \n> git commands in the default path drop rather sooner than later.\n\nI agree with the first sentence. And yes I am playing it safe, and at\nthe same time I do not think the \"default\" really matters as much as\npeople think.\n\nIf people are really serious about reducing the number of commands in\nthe path, I would expect fixes and bugreports saying \"I am setting\ngitexecdir different from bindir in _my_ installation when I build git,\nand here are the things that does not work if I do so\". Within the span\nof more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I\ndo not think there was a single such report or patch, other than the\nmessage from Nguyen that started this thread.\n\nWhich means one of two things (1) we got everything right and there is\nnothing to fix, other than changing the default like Nguyen's patch\ndoes, or (2) nobody is interested in moving git-foo out of their PATH\nfor _his_ own use, but pushing changes that would affect _other_ people\nwithout testing.\n\nI am of course hoping that (1) is the case. And it could be that in\nopen-source settings often the silent majority is content with what's\nalready there, and that many people who are indeed interested in moving\ngit-foo out of their PATH are doing so happily without telling the\nothers of their success.\n\nBut it still worries me.\n\nAnd people's scripts, especially old/unmaintained ones that google still\nknows about, are worrysome too. Didn't we just see a message that says\n\"git-update-cache in a script I picked up from google does not work\" on\nthe list?\n"},{"id":"61432","messageId":"20071129231444.GA9616@coredump.intra.peff.net","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711292218240.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-29T23:14:44Z","receivedAt":"2007-11-29T23:14:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 10:19:16PM +0000, Johannes Schindelin wrote:\n\n> > I think that is totally reasonable, as on those platforms there is\n> > actually something to be gained from removing those hardlinks (you could\n> \n> Note that one big problem with a few platforms having dash forms and \n> others not is that you _will_ get scripts and aliases that do not work \n> everywhere.\n> \n> Consistency is good.\n\nYes, I am fine with the user having to go to extra lengths to use the\ndash forms (like adding $(libexecdir) to their path), which I think\nshould address your consistency concern.\n\n-Peff\n"},{"id":"61433","messageId":"alpine.LFD.0.9999.0711291527090.8458@woody.linux-foundation.org","threadId":"11033","inReplyTo":"20071129231444.GA9616@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-29T23:30:05Z","receivedAt":"2007-11-29T23:30:05Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 29 Nov 2007, Jeff King wrote:\n> \n> Yes, I am fine with the user having to go to extra lengths to use the\n> dash forms (like adding $(libexecdir) to their path), which I think\n> should address your consistency concern.\n\nI agree. If we actually start moving the subcommands into a separate \ndirectory, I suspect scripts will be fixed up soon enough. Of course \npeople *can* do it by just adding the path, but more likely, we'll just \nsee people start doign \"git xyz\" instead of \"git-xyz\".\n\nAnd from a consistency standpoint, that would be a *good* thing. There are \nmany reasons why the git-xyz format *cannot* be the \"consistent\" form\n(ranging from the flags like --bare and -p to just aliases), so \nencouraging people to move to \"git xyz\" is just a good idea.\n\nYeah, yeah, the man-pages need the \"git-xyz\" form, but on the other hand, \nrather than \"man git-xyz\", you can just do \"git help xyz\" instead, and now \nyou're consistently avoiding the dash again!\n\n\t\t\tLinus\n"},{"id":"61435","messageId":"7veje8twt2.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"alpine.LFD.0.9999.0711291527090.8458@woody.linux-foundation.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-30T00:13:29Z","receivedAt":"2007-11-30T00:13:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And from a consistency standpoint, that would be a *good* thing. There are \n> many reasons why the git-xyz format *cannot* be the \"consistent\" form\n> (ranging from the flags like --bare and -p to just aliases), so \n> encouraging people to move to \"git xyz\" is just a good idea.\n>\n> Yeah, yeah, the man-pages need the \"git-xyz\" form, but on the other hand, \n> rather than \"man git-xyz\", you can just do \"git help xyz\" instead, and now \n> you're consistently avoiding the dash again!\n\nOk. So here is a revised roadmap that a panda brain (that is not so\nwell working today due to fever) came up.\n\n - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n release notes for the version will warn users that:\n\n (1) using git-foo from the command line, and\n\n (2) using git-foo from your scripts without first prepending the\n return value of \"git --exec-path\" to the PATH\n\n is now officially deprecated (it has been deprecated for a long time\n since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n the default configuration that does not install git-foo form in\n user's PATH.\n\n If further will warn users that git-foo form will be removed in\n v1.5.6 for many commands and it will be merely an accident if some of\n them still work after that.\n\n - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This\n will also affect the sample RPM spec and resulting RPM binary\n packages I will place on k.org, and I'll ask Gerrit to do the same on\n Debian side. The official binary packaging of individual distros are\n not under my control, but if there is a handy list of people I can\n send this notice to for other distros, that would help this process.\n\n - The release notes for v1.5.5 will warn users again that git-foo will\n be removed in v1.5.6 for many commands and it will be merely an\n accident if some of them still work.\n\n - Post v1.5.5, start cooking the change that does not install hardlinks\n for built-in commands, aiming for inclusion in v1.5.6, in May-Jun\n 2008 timeframe.\n"},{"id":"61438","messageId":"20071130003512.GB11683@coredump.intra.peff.net","threadId":"11033","inReplyTo":"7veje8twt2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T00:35:12Z","receivedAt":"2007-11-30T00:35:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 04:13:29PM -0800, Junio C Hamano wrote:\n\n> - Post v1.5.5, start cooking the change that does not install hardlinks\n> for built-in commands, aiming for inclusion in v1.5.6, in May-Jun\n> 2008 timeframe.\n\nI am still against this step, for the reasons mentioned in the mails\nleading up to the one you just quoted. I am fine with \"does not install\nhardlinks for builtin-commands on systems that don't support hardlinks\"\n(and of course all such hardlinks are in $(libexecdir)/git-core at this\npoint).\n\n-Peff\n"},{"id":"61441","messageId":"fcaeb9bf0711291640p52cb46fdo97e286e34c4e0527@mail.gmail.com","threadId":"11033","inReplyTo":"7veje8twt2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-30T00:40:27Z","receivedAt":"2007-11-30T00:40:27Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 30, 2007 7:13 AM, Junio C Hamano wrote:\n> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n> for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This\n> will also affect the sample RPM spec and resulting RPM binary\n> packages I will place on k.org, and I'll ask Gerrit to do the same on\n> Debian side. The official binary packaging of individual distros are\n> not under my control, but if there is a handy list of people I can\n> send this notice to for other distros, that would help this process.\n\nYou can find Gentoo maintainers here:\n\nhttp://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-util/git/metadata.xml?rev=1.6&view=markup\n\n-- \nDuy\n"},{"id":"61444","messageId":"7vzlwwsgkp.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"20071130003512.GB11683@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-30T00:49:26Z","receivedAt":"2007-11-30T00:49:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Nov 29, 2007 at 04:13:29PM -0800, Junio C Hamano wrote:\n>\n>> - Post v1.5.5, start cooking the change that does not install hardlinks\n>> for built-in commands, aiming for inclusion in v1.5.6, in May-Jun\n>> 2008 timeframe.\n>\n> I am still against this step, for the reasons mentioned in the mails\n> leading up to the one you just quoted. I am fine with \"does not install\n> hardlinks for builtin-commands on systems that don't support hardlinks\"\n> (and of course all such hardlinks are in $(libexecdir)/git-core at this\n> point).\n\nI understand your point was primarily \"git-a\". I think it has been\nsolved for bash and zsh but not for other shells. I think possible and\nsensible avenues are (1) punt -- cvs, svn nor hg people do not seem to\nhave problem with it, or (2) implement completion in your other favorite\nshells.\n\nAnd I think the following from Linus makes sense.\n\n> And from a consistency standpoint, that would be a *good* thing. There are \n> many reasons why the git-xyz format *cannot* be the \"consistent\" form\n> (ranging from the flags like --bare and -p to just aliases), so \n> encouraging people to move to \"git xyz\" is just a good idea.\n>\n> Yeah, yeah, the man-pages need the \"git-xyz\" form, but on the other hand, \n> rather than \"man git-xyz\", you can just do \"git help xyz\" instead, and now \n> you're consistently avoiding the dash again!\n\nbut I am feeling quite feverish today so I may be missing something\nobvious.\n"},{"id":"61445","messageId":"474F5E90.9040505@gmail.com","threadId":"11033","inReplyTo":"7veje8twt2.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2007-11-30T00:51:28Z","receivedAt":"2007-11-30T00:51:28Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n[...]\n> Ok. So here is a revised roadmap that a panda brain (that is not so\n> well working today due to fever) came up.\n> \n> - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n> release notes for the version will warn users that:\n> \n> (1) using git-foo from the command line, and\n> \n> (2) using git-foo from your scripts without first prepending the\n> return value of \"git --exec-path\" to the PATH\n> \n> is now officially deprecated (it has been deprecated for a long time\n> since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n> the default configuration that does not install git-foo form in\n> user's PATH.\n> \n> If further will warn users that git-foo form will be removed in\n> v1.5.6 for many commands and it will be merely an accident if some of\n> them still work after that.\n> \n> - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n> for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This\n> will also affect the sample RPM spec and resulting RPM binary\n> packages I will place on k.org, and I'll ask Gerrit to do the same on\n> Debian side. The official binary packaging of individual distros are\n> not under my control, but if there is a handy list of people I can\n> send this notice to for other distros, that would help this process.\n> \n> - The release notes for v1.5.5 will warn users again that git-foo will\n> be removed in v1.5.6 for many commands and it will be merely an\n> accident if some of them still work.\n> \n> - Post v1.5.5, start cooking the change that does not install hardlinks\n> for built-in commands, aiming for inclusion in v1.5.6, in May-Jun\n> 2008 timeframe.\n\nAgain, there needs to remain support in the Makefile to install the \n\"dashed\" versions of the commands for those that want it; and be able to \nset gitexecdir=$(binder) without editing the Makefile.\n"},{"id":"61446","messageId":"alpine.LFD.0.99999.0711291950590.9605@xanadu.home","threadId":"11033","inReplyTo":"20071130003512.GB11683@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T00:52:01Z","receivedAt":"2007-11-30T00:52:01Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, Jeff King wrote:\n\n> On Thu, Nov 29, 2007 at 04:13:29PM -0800, Junio C Hamano wrote:\n> \n> > - Post v1.5.5, start cooking the change that does not install hardlinks\n> > for built-in commands, aiming for inclusion in v1.5.6, in May-Jun\n> > 2008 timeframe.\n> \n> I am still against this step, for the reasons mentioned in the mails\n> leading up to the one you just quoted. I am fine with \"does not install\n> hardlinks for builtin-commands on systems that don't support hardlinks\"\n> (and of course all such hardlinks are in $(libexecdir)/git-core at this\n> point).\n\nBut only for porcelain, right? You certainly don't need the dashed form \nof plumbing commands?\n\n\nNicolas\n"},{"id":"61447","messageId":"Pine.LNX.4.64.0711300053260.27959@racer.site","threadId":"11033","inReplyTo":"474F5E90.9040505@gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T00:54:26Z","receivedAt":"2007-11-30T00:54:26Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 29 Nov 2007, A Large Angry SCM wrote:\n\n> Junio C Hamano wrote:\n> [...]\n> > Ok. So here is a revised roadmap that a panda brain (that is not so\n> > well working today due to fever) came up.\n> > \n> > - v1.5.4 will ship with gitexecdir=$(bindir) in Makefile. But the\n> > release notes for the version will warn users that:\n> > \n> > (1) using git-foo from the command line, and\n> > \n> > (2) using git-foo from your scripts without first prepending the\n> > return value of \"git --exec-path\" to the PATH\n> > \n> > is now officially deprecated (it has been deprecated for a long time\n> > since January 2006, v1.2.0~149) and upcoming v1.5.5 will ship with\n> > the default configuration that does not install git-foo form in\n> > user's PATH.\n> > \n> > If further will warn users that git-foo form will be removed in\n> > v1.5.6 for many commands and it will be merely an accident if some of\n> > them still work after that.\n> > \n> > - Post v1.5.4, start cooking gitexecdir=$(libexecdir)/git-core, aiming\n> > for inclusion in v1.5.5, perhaps in Feb-Mar 2008 timeframe. This\n> > will also affect the sample RPM spec and resulting RPM binary\n> > packages I will place on k.org, and I'll ask Gerrit to do the same on\n> > Debian side. The official binary packaging of individual distros are\n> > not under my control, but if there is a handy list of people I can\n> > send this notice to for other distros, that would help this process.\n> > \n> > - The release notes for v1.5.5 will warn users again that git-foo will\n> > be removed in v1.5.6 for many commands and it will be merely an\n> > accident if some of them still work.\n> > \n> > - Post v1.5.5, start cooking the change that does not install hardlinks\n> > for built-in commands, aiming for inclusion in v1.5.6, in May-Jun\n> > 2008 timeframe.\n> \n> Again, there needs to remain support in the Makefile to install the \"dashed\"\n> versions of the commands for those that want it; and be able to set\n> gitexecdir=$(binder) without editing the Makefile.\n\nUmm. Why? If there is no compelling reason (and you named none, but \nthere were quite a few reasons against it), why should the Makefile \nsupport the dash form after 1.5.6?\n\nCiao,\nDscho\n"},{"id":"61448","messageId":"20071130005852.GA12224@coredump.intra.peff.net","threadId":"11033","inReplyTo":"7vzlwwsgkp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T00:58:52Z","receivedAt":"2007-11-30T00:58:52Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 04:49:26PM -0800, Junio C Hamano wrote:\n\n> I understand your point was primarily \"git-a\". I think it has been\n> solved for bash and zsh but not for other shells. I think possible and\n> sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to\n> have problem with it, or (2) implement completion in your other favorite\n> shells.\n\nMy point is that (2) is already implemented for every program (shell or\nno) which understands filename completion, and there is a proposal for\ntaking it away. I would consider that, except I haven't see any claimed\nadvantages except that the hardlinks are awful under Windows.\n\nI am proposing to have those dashed forms on platforms where it makes\nsense, but to treat them as second-class citizens (by putting them in\n$(libexecdir), which will address consistency problems.\n\n> And I think the following from Linus makes sense.\n> \n> > And from a consistency standpoint, that would be a *good* thing. There are \n> > many reasons why the git-xyz format *cannot* be the \"consistent\" form\n> > (ranging from the flags like --bare and -p to just aliases), so \n> > encouraging people to move to \"git xyz\" is just a good idea.\n> >\n> > Yeah, yeah, the man-pages need the \"git-xyz\" form, but on the other hand, \n> > rather than \"man git-xyz\", you can just do \"git help xyz\" instead, and now \n> > you're consistently avoiding the dash again!\n> \n> but I am feeling quite feverish today so I may be missing something\n> obvious.\n\nI thought Linus' point was that moving the subcommands was sufficient\nfor dealing with the consistency issue (i.e., all scripts would move to\n\"git foo\" and only those people who really wanted to would put the\ndashed forms in their path). From the same email you quoted, but just\nabove:\n\n> On Thu, 29 Nov 2007, Jeff King wrote:\n> >\n> > Yes, I am fine with the user having to go to extra lengths to use the\n> > dash forms (like adding $(libexecdir) to their path), which I think\n> > should address your consistency concern.\n> \n> I agree. If we actually start moving the subcommands into a separate\n> directory, I suspect scripts will be fixed up soon enough. Of course\n> people *can* do it by just adding the path, but more likely, we'll just\n> see people start doign \"git xyz\" instead of \"git-xyz\".\n\nBut now we are arguing about what Linus meant like it is scripture. ;)\n\n-Peff\n"},{"id":"61450","messageId":"20071130010055.GB12224@coredump.intra.peff.net","threadId":"11033","inReplyTo":"alpine.LFD.0.99999.0711291950590.9605@xanadu.home","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T01:00:55Z","receivedAt":"2007-11-30T01:00:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 07:52:01PM -0500, Nicolas Pitre wrote:\n\n> > I am still against this step, for the reasons mentioned in the mails\n> > leading up to the one you just quoted. I am fine with \"does not install\n> > hardlinks for builtin-commands on systems that don't support hardlinks\"\n> > (and of course all such hardlinks are in $(libexecdir)/git-core at this\n> > point).\n> \n> But only for porcelain, right? You certainly don't need the dashed form \n> of plumbing commands?\n\nIn principle, yes, though one man's porcelain is another man's plumbing,\nso determining the correct set is hard (and why bother if they are all\nhidden from mere mortals, anyway?).\n\nPerhaps because I am actively working on git, I tend to use a fair\nnumber of plumbing commands for under-the-hood inspection and\nexperimentation.\n\n-Peff\n"},{"id":"61451","messageId":"alpine.LFD.0.99999.0711291959510.9605@xanadu.home","threadId":"11033","inReplyTo":"474F5E90.9040505@gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T01:01:16Z","receivedAt":"2007-11-30T01:01:16Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, A Large Angry SCM wrote:\n\n> Again, there needs to remain support in the Makefile to install the \"dashed\"\n> versions of the commands for those that want it; and be able to set\n> gitexecdir=$(binder) without editing the Makefile.\n\nWell, if you want a \"non standard\" installation, maybe you just can edit \na line or two in the Makefile?\n\n\nNicolas\n"},{"id":"61454","messageId":"alpine.LFD.0.99999.0711292004340.9605@xanadu.home","threadId":"11033","inReplyTo":"20071130005852.GA12224@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T01:13:04Z","receivedAt":"2007-11-30T01:13:04Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, Jeff King wrote:\n\n> On Thu, Nov 29, 2007 at 04:49:26PM -0800, Junio C Hamano wrote:\n> \n> > I understand your point was primarily \"git-a\". I think it has been\n> > solved for bash and zsh but not for other shells. I think possible and\n> > sensible avenues are (1) punt -- cvs, svn nor hg people do not seem to\n> > have problem with it, or (2) implement completion in your other favorite\n> > shells.\n> \n> My point is that (2) is already implemented for every program (shell or\n> no) which understands filename completion, and there is a proposal for\n> taking it away. I would consider that, except I haven't see any claimed\n> advantages except that the hardlinks are awful under Windows.\n\nWeren't enough complaints about Git having waaaaaaaaaaay too many \ncommands? Didn't those complaints come about often enough already?\n\n\t$ git-[tab]\n\tDisplay all 135 possibilities? (y or n)\n\n\nNicolas\n"},{"id":"61455","messageId":"20071130011748.GC11683@coredump.intra.peff.net","threadId":"11033","inReplyTo":"alpine.LFD.0.99999.0711292004340.9605@xanadu.home","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T01:17:48Z","receivedAt":"2007-11-30T01:17:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 08:13:04PM -0500, Nicolas Pitre wrote:\n\n> > My point is that (2) is already implemented for every program (shell or\n> > no) which understands filename completion, and there is a proposal for\n> > taking it away. I would consider that, except I haven't see any claimed\n> > advantages except that the hardlinks are awful under Windows.\n> \n> Weren't enough complaints about Git having waaaaaaaaaaay too many \n> commands? Didn't those complaints come about often enough already?\n> \n> \t$ git-[tab]\n> \tDisplay all 135 possibilities? (y or n)\n\nGo back and read the thread to which you are responding. I am _not_\narguing against moving those commands to $(libexecdir) where no sane\nuser will ever see them. That change addresses the issue you are talking\nabout.\n\nI _am_ arguing against removing them entirely, for those of us who want\nto go to the trouble of enabling this (by putting a non-standard entry\ninto our PATH). Because the issue you are talking about will already\nhave been dealt with, it is no longer a compelling reason to remove the\nhardlinks entirely.\n\nThe only reason I have heard to remove them entirely is that Windows\ndoesn't properly support hardlinks, which I addressed in my other mails\n(and to which I have seen no rebuttal).\n\n-Peff\n"},{"id":"61457","messageId":"alpine.LFD.0.99999.0711292013580.9605@xanadu.home","threadId":"11033","inReplyTo":"20071130010055.GB12224@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T01:19:38Z","receivedAt":"2007-11-30T01:19:38Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, Jeff King wrote:\n\n> On Thu, Nov 29, 2007 at 07:52:01PM -0500, Nicolas Pitre wrote:\n> \n> > > I am still against this step, for the reasons mentioned in the mails\n> > > leading up to the one you just quoted. I am fine with \"does not install\n> > > hardlinks for builtin-commands on systems that don't support hardlinks\"\n> > > (and of course all such hardlinks are in $(libexecdir)/git-core at this\n> > > point).\n> > \n> > But only for porcelain, right? You certainly don't need the dashed form \n> > of plumbing commands?\n> \n> In principle, yes, though one man's porcelain is another man's plumbing,\n> so determining the correct set is hard (and why bother if they are all\n> hidden from mere mortals, anyway?).\n\nThat would be a good reason not to bother determining which set to \npreserve and remove them all then.\n\nSure you'll miss the dashed form for, say, one week? After that your \nfingers should be retrained.\n\n\nNicolas\n"},{"id":"61458","messageId":"20071130012536.GA12615@coredump.intra.peff.net","threadId":"11033","inReplyTo":"alpine.LFD.0.99999.0711292013580.9605@xanadu.home","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T01:25:36Z","receivedAt":"2007-11-30T01:25:36Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 08:19:38PM -0500, Nicolas Pitre wrote:\n\n> > In principle, yes, though one man's porcelain is another man's plumbing,\n> > so determining the correct set is hard (and why bother if they are all\n> > hidden from mere mortals, anyway?).\n> \n> That would be a good reason not to bother determining which set to \n> preserve and remove them all then.\n\nIt clearly argues for putting all in the same boat, yes (but obviously\nwe disagree on which boat).\n\n> Sure you'll miss the dashed form for, say, one week? After that your \n> fingers should be retrained.\n\nPerhaps, although that doesn't address my other point, about non-bash\nprogram in the world which already does filename completion (in my case,\nI am specifically thinking about vim's \":r!\", but surely emacs users\nmust have a similar issue).\n\nBut that is just talking about the disadvantages; you can argue that\nthey are small, but they are clearly non-zero. More importantly, what\nare the _advantages_ of removing the hardlinks (and if you haven't read\nthe other message I just sent you, I am talking not about putting\nhardlinks into a non-PATH directory, but about removing them entirely\nonce they are already in that alternate directory)? If there aren't any\nadvantages, or they are also small, then it makes sense to keep the\nhardlinks.\n\n-Peff\n"},{"id":"61460","messageId":"alpine.LFD.0.99999.0711292029420.9605@xanadu.home","threadId":"11033","inReplyTo":"20071130012536.GA12615@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T01:33:39Z","receivedAt":"2007-11-30T01:33:39Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, Jeff King wrote:\n\n> On Thu, Nov 29, 2007 at 08:19:38PM -0500, Nicolas Pitre wrote:\n> \n> > > In principle, yes, though one man's porcelain is another man's plumbing,\n> > > so determining the correct set is hard (and why bother if they are all\n> > > hidden from mere mortals, anyway?).\n> > \n> > That would be a good reason not to bother determining which set to \n> > preserve and remove them all then.\n> \n> It clearly argues for putting all in the same boat, yes (but obviously\n> we disagree on which boat).\n> \n> > Sure you'll miss the dashed form for, say, one week? After that your \n> > fingers should be retrained.\n> \n> Perhaps, although that doesn't address my other point, about non-bash\n> program in the world which already does filename completion (in my case,\n> I am specifically thinking about vim's \":r!\", but surely emacs users\n> must have a similar issue).\n> \n> But that is just talking about the disadvantages; you can argue that\n> they are small, but they are clearly non-zero. More importantly, what\n> are the _advantages_ of removing the hardlinks (and if you haven't read\n> the other message I just sent you, I am talking not about putting\n> hardlinks into a non-PATH directory, but about removing them entirely\n> once they are already in that alternate directory)? If there aren't any\n> advantages, or they are also small, then it makes sense to keep the\n> hardlinks.\n\nSo what you want is for the dashed hardlinks to exist _inside_ the \nlibexec directory, even if most people won't \"see\" them due to that \nlibexec directory not being in the shell path, right?\n\nIf that is what you mean then I personally don't care at all.\n\n\nNicolas\n"},{"id":"61461","messageId":"20071130015315.GA13369@coredump.intra.peff.net","threadId":"11033","inReplyTo":"alpine.LFD.0.99999.0711292029420.9605@xanadu.home","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T01:53:15Z","receivedAt":"2007-11-30T01:53:15Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 29, 2007 at 08:33:39PM -0500, Nicolas Pitre wrote:\n\n> So what you want is for the dashed hardlinks to exist _inside_ the \n> libexec directory, even if most people won't \"see\" them due to that \n> libexec directory not being in the shell path, right?\n> \n> If that is what you mean then I personally don't care at all.\n\nThat is exactly what I mean.\n\n-Peff\n"},{"id":"61464","messageId":"474F6F7C.5050409@gmail.com","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711300053260.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2007-11-30T02:03:40Z","receivedAt":"2007-11-30T02:03:40Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 29 Nov 2007, A Large Angry SCM wrote:\n[...]\n>> Again, there needs to remain support in the Makefile to install the \"dashed\"\n>> versions of the commands for those that want it; and be able to set\n>> gitexecdir=$(binder) without editing the Makefile.\n> \n> Umm. Why? If there is no compelling reason (and you named none, but \n> there were quite a few reasons against it), why should the Makefile \n> support the dash form after 1.5.6?\n\nNot all shells support customized command completion (check the \narchives); \"bang\" history (check the archives); etc.\n"},{"id":"61465","messageId":"474F72B7.9000305@gmail.com","threadId":"11033","inReplyTo":"alpine.LFD.0.99999.0711291959510.9605@xanadu.home","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2007-11-30T02:17:27Z","receivedAt":"2007-11-30T02:17:27Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Thu, 29 Nov 2007, A Large Angry SCM wrote:\n> \n>> Again, there needs to remain support in the Makefile to install the \"dashed\"\n>> versions of the commands for those that want it; and be able to set\n>> gitexecdir=$(binder) without editing the Makefile.\n> \n> Well, if you want a \"non standard\" installation, maybe you just can edit \n> a line or two in the Makefile?\n\nWhy do you object to a \"install-dashed\" Makefile target?\n"},{"id":"61467","messageId":"474F740F.1000008@gmail.com","threadId":"11033","inReplyTo":"20071130015315.GA13369@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2007-11-30T02:23:11Z","receivedAt":"2007-11-30T02:23:11Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jeff King wrote:\n> On Thu, Nov 29, 2007 at 08:33:39PM -0500, Nicolas Pitre wrote:\n> \n>> So what you want is for the dashed hardlinks to exist _inside_ the \n>> libexec directory, even if most people won't \"see\" them due to that \n>> libexec directory not being in the shell path, right?\n>>\n>> If that is what you mean then I personally don't care at all.\n> \n> That is exactly what I mean.\n\nAnd that also works for me when I set libexec=$(bindir).\n"},{"id":"61468","messageId":"alpine.LFD.0.99999.0711292124430.9605@xanadu.home","threadId":"11033","inReplyTo":"474F72B7.9000305@gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T02:27:19Z","receivedAt":"2007-11-30T02:27:19Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, A Large Angry SCM wrote:\n\n> Nicolas Pitre wrote:\n> > On Thu, 29 Nov 2007, A Large Angry SCM wrote:\n> > \n> > > Again, there needs to remain support in the Makefile to install the\n> > > \"dashed\"\n> > > versions of the commands for those that want it; and be able to set\n> > > gitexecdir=$(binder) without editing the Makefile.\n> > \n> > Well, if you want a \"non standard\" installation, maybe you just can edit a\n> > line or two in the Makefile?\n> \n> Why do you object to a \"install-dashed\" Makefile target?\n\nAs long as it is not the default I don't object.\n\n\nNicolas\n"},{"id":"61469","messageId":"alpine.LFD.0.9999.0711291821220.8458@woody.linux-foundation.org","threadId":"11033","inReplyTo":"20071130005852.GA12224@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-30T02:29:41Z","receivedAt":"2007-11-30T02:29:41Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 29 Nov 2007, Jeff King wrote:\n> \n> I thought Linus' point was that moving the subcommands was sufficient\n> for dealing with the consistency issue (i.e., all scripts would move to\n> \"git foo\" and only those people who really wanted to would put the\n> dashed forms in their path). \n\nYes. I meant that we might as well keep all the git-xyz forms around, but \n_only_ in the libexec directory (and make sure that the libexec directory \nby default is *not* a binary directory), so that they'd normally not be \nvisible.\n\nSo then, people who want to use the old-fashioned git-xyz forms, because \nthey just really hate white-space or whatever, could choose to do one of \ntwo things:\n - either just change the default libexec directory to be the same as the \n binary install directory, and have all the git-xyz things in the same \n place they've always been.\n - or just add $(gitlibexec) into their path.\n\nbut the default (which is what 99% of all people use) would be to not \nshow them. I also think that it makes sense to avoid wasting diskspace \nwith duplicate files, so in situations where you don't have hardlinks, \njust don't install the git-xyz files at all by default (and again, maybe \nwe can have a option to the installer to do it for people who really are \nvery attached to the git-xyz format, and prefer to waste even a lot of \ndisk on it)\n\nSo I just think that the whole idiotic complaint that some people have \n(that whole \"git-\" shows \"Display all 144 possibilities?\" and \npeople are somehow using that as an argument that git is \"complex\") should \nbe something we strive to undo. I think the complaint is insane (because \nthe answer is \"well, nobody forces you to _use_ all the power and scripts \nwe give you!\"), but still, it's a complaint, so let's just assume the user \nis right, and try to fix it.\n\nSo when you do \"git-\" it should just beep at you and not show \nanything at all by default. And when you do \"git \", we should \nmake sure that the bash expansion (or zsh or whatever) shows a nice \ncollection of common plumbing, not soemthing really scary.\n\n\t\t\tLinus\n"},{"id":"61473","messageId":"alpine.LFD.0.99999.0711292142550.9605@xanadu.home","threadId":"11033","inReplyTo":"alpine.LFD.0.9999.0711291821220.8458@woody.linux-foundation.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-11-30T02:55:16Z","receivedAt":"2007-11-30T02:55:16Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 29 Nov 2007, Linus Torvalds wrote:\n\n> Yes. I meant that we might as well keep all the git-xyz forms around, but \n> _only_ in the libexec directory (and make sure that the libexec directory \n> by default is *not* a binary directory), so that they'd normally not be \n> visible.\n> \n> So then, people who want to use the old-fashioned git-xyz forms, because \n> they just really hate white-space or whatever, could choose to do one of \n> two things:\n> - either just change the default libexec directory to be the same as the \n> binary install directory, and have all the git-xyz things in the same \n> place they've always been.\n> - or just add $(gitlibexec) into their path.\n> \n> but the default (which is what 99% of all people use) would be to not \n> show them. I also think that it makes sense to avoid wasting diskspace \n> with duplicate files, so in situations where you don't have hardlinks, \n> just don't install the git-xyz files at all by default (and again, maybe \n> we can have a option to the installer to do it for people who really are \n> very attached to the git-xyz format, and prefer to waste even a lot of \n> disk on it)\n> \n> So I just think that the whole idiotic complaint that some people have \n> (that whole \"git-\" shows \"Display all 144 possibilities?\" and \n> people are somehow using that as an argument that git is \"complex\") should \n> be something we strive to undo. I think the complaint is insane (because \n> the answer is \"well, nobody forces you to _use_ all the power and scripts \n> we give you!\"), but still, it's a complaint, so let's just assume the user \n> is right, and try to fix it.\n\nAbsolutely!\n\nAnd despite Junio's appearance of some cowardliness on this issue :-)\nI think we should have this right now instead of later. Like Junio said \nhimself, this was planned for a while already, and poorly maintained \nexternal scripts are already failing due to other reasons anyway.\n\n\nNicolas\n"},{"id":"61476","messageId":"1BC9698A-80D3-4189-B24B-7E3C4934B043@zib.de","threadId":"11033","inReplyTo":"20071130011748.GC11683@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-30T05:42:13Z","receivedAt":"2007-11-30T05:42:13Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 30, 2007, at 2:17 AM, Jeff King wrote:\n\n>\n> The only reason I have heard to remove them entirely is that Windows\n> doesn't properly support hardlinks, which I addressed in my other \n> mails\n> (and to which I have seen no rebuttal).\n\nWe don't have a problem with hardlinks for git-* commands in\nmsysgit. The msysgit installer already creates hardlinks if\ninstalling on NTFS. On non-NTFS partitions, though, it needs\nto copy the files.\n\nNote, this doesn't mean we love hardlinks in msysgit. Actually,\nmsys does _not_ support them in its Unix emulation layer. So,\nfor daily work git does not have hardlinks. For examples, the\ntest script skip all hardlink related tests. The installer\nhandles hardlinks using the Windows API directly and not using\nthe Unix emulation layer.\n\nWe already have a setup that supports exporting only git and\ngitk to the a Windows Command Prompt (not the bash that comes\nwith msysgit). If you choose this setup, a directory that\ncontains only these two commands will be added to the system\nwide PATH. We use this indirection to hide all the the Unix\ntools that are included in msysgit (and needed by git) from\nthe Windows Command Prompt.\n\n\tSteffen\n"},{"id":"61477","messageId":"5E2A9E2B-8B9A-46B0-99D0-DB3798F10119@zib.de","threadId":"11033","inReplyTo":"alpine.LFD.0.9999.0711291821220.8458@woody.linux-foundation.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-11-30T05:51:35Z","receivedAt":"2007-11-30T05:51:35Z","isPatch":true,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Nov 30, 2007, at 3:29 AM, Linus Torvalds wrote:\n\n> So I just think that the whole idiotic complaint that some people have\n> (that whole \"git-\" shows \"Display all 144 possibilities?\" \n> and\n> people are somehow using that as an argument that git is \"complex\") \n> should\n> be something we strive to undo. I think the complaint is insane \n> (because\n> the answer is \"well, nobody forces you to _use_ all the power and \n> scripts\n> we give you!\"), but still, it's a complaint, so let's just assume \n> the user\n> is right, and try to fix it.\n>\n> So when you do \"git-\" it should just beep at you and not \n> show\n> anything at all by default. And when you do \"git \", we \n> should\n> make sure that the bash expansion (or zsh or whatever) shows a nice\n> collection of common plumbing, not soemthing really scary.\n\n\nWhat will happen to gitk?\n\nShouldn't it be included in the nice collection? gitk is\nan essential command. Then, following your reasoning,\n\"git \" should recommend it, no?\n\nNote, \"git gui\" already works. gitk would really be the last\ngit \"command\" that can't be accessed through \"git \"\n\n\tSteffen\n"},{"id":"61483","messageId":"474FB938.3040209@op5.se","threadId":"11033","inReplyTo":"20071130011748.GC11683@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-11-30T07:18:16Z","receivedAt":"2007-11-30T07:18:16Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Thu, Nov 29, 2007 at 08:13:04PM -0500, Nicolas Pitre wrote:\n> \n>>> My point is that (2) is already implemented for every program (shell or\n>>> no) which understands filename completion, and there is a proposal for\n>>> taking it away. I would consider that, except I haven't see any claimed\n>>> advantages except that the hardlinks are awful under Windows.\n>> Weren't enough complaints about Git having waaaaaaaaaaay too many \n>> commands? Didn't those complaints come about often enough already?\n>>\n>> \t$ git-[tab]\n>> \tDisplay all 135 possibilities? (y or n)\n> \n> Go back and read the thread to which you are responding. I am _not_\n> arguing against moving those commands to $(libexecdir) where no sane\n> user will ever see them. That change addresses the issue you are talking\n> about.\n> \n> I _am_ arguing against removing them entirely, for those of us who want\n> to go to the trouble of enabling this (by putting a non-standard entry\n> into our PATH). Because the issue you are talking about will already\n> have been dealt with, it is no longer a compelling reason to remove the\n> hardlinks entirely.\n> \n> The only reason I have heard to remove them entirely is that Windows\n> doesn't properly support hardlinks, which I addressed in my other mails\n> (and to which I have seen no rebuttal).\n> \n\nIt would provide a ui inconsistency between platforms. Several people\npointed that out. It's decidedly a Bad Thing.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"61484","messageId":"BE2DD4F6-2F40-47DD-ADBF-E549EAF634C2@wincent.com","threadId":"11033","inReplyTo":"7vd4tsvfvk.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-11-30T07:32:57Z","receivedAt":"2007-11-30T07:32:57Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 29/11/2007, a las 23:36, Junio C Hamano escribió:\n\n> If people are really serious about reducing the number of commands in\n> the path, I would expect fixes and bugreports saying \"I am setting\n> gitexecdir different from bindir in _my_ installation when I build \n> git,\n> and here are the things that does not work if I do so\". Within the \n> span\n> of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I\n> do not think there was a single such report or patch, other than the\n> message from Nguyen that started this thread.\n\nOne reason why there have been no reports is probably because 99% of \npeople have never heard of gitexecdir nor know what it does.\n\n$ git grep gitexecdir | awk -F : '{print $1}' | uniq\nMakefile\nconfig.mak.in\ngit-gui/Makefile\ngit-gui/macosx/AppMain.tcl\ngit.c\n\nTry googling for \"site:git.or.cz gitexecdir\"\n\nBasically, seems the only way you could know about it is if you've \nheard it mentioned on this mailing list and decided to study the \nMakefile.\n\nCheers,\nWincent\n"},{"id":"61499","messageId":"DB613F3E-85CC-4AF0-928C-4F4E4C8E9FB8@orakel.ntnu.no","threadId":"11033","inReplyTo":"7vd4tsvfvk.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git-list@orakel.ntnu.no","sentAt":"2007-11-30T11:28:18Z","receivedAt":"2007-11-30T11:28:18Z","isPatch":true,"sender":{"key":"eyvind-git-list@orakel.ntnu.no","avatar":null},"body":"On 29. nov. 2007, at 23.36, Junio C Hamano wrote:\n\n[...]\n\n> If people are really serious about reducing the number of commands in\n> the path, I would expect fixes and bugreports saying \"I am setting\n> gitexecdir different from bindir in _my_ installation when I build \n> git,\n> and here are the things that does not work if I do so\". Within the \n> span\n> of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I\n> do not think there was a single such report or patch, other than the\n> message from Nguyen that started this thread.\n\nI'm setting gitexecdir different from bindir in my installation, and \nhere are the things that don't work:\n\n- When pushing to my system over ssh, git-receive-pack and git-upload- \npack are expected to be in $PATH. I resolved the problem by putting \nsymlinks in /usr/local/bin.\n\nI haven't seen any other problems, but then again, I only use git \nplumbing commands and my own scripts.\n\nEyvind\n"},{"id":"61498","messageId":"Pine.LNX.4.64.0711301207020.27959@racer.site","threadId":"11033","inReplyTo":"DB613F3E-85CC-4AF0-928C-4F4E4C8E9FB8@orakel.ntnu.no","subject":"[PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T12:08:20Z","receivedAt":"2007-11-30T12:08:20Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nSince we plan to move the dash-form (git-) into an execdir, it\nmake sense to prepare our git protocol users for it.\n\nNoticed by Eyvind Bernhardsen.\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Fri, 30 Nov 2007, Eyvind Bernhardsen wrote:\n\n\t> - When pushing to my system over ssh, git-receive-pack and\n\t> git-upload-pack are expected to be in $PATH. I resolved the \n\t> problem by putting symlinks in /usr/local/bin.\n\n\tHow about this? (I only compile-tested it...)\n\n transport.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/transport.c b/transport.c\nindex 50db980..7bd0846 100644\n--- a/transport.c\n+++ b/transport.c\n@@ -736,10 +736,10 @@ struct transport *transport_get(struct remote *remote, const char *url)\n \t\tret->disconnect = disconnect_git;\n \n \t\tdata->thin = 1;\n-\t\tdata->uploadpack = \"git-upload-pack\";\n+\t\tdata->uploadpack = \"git upload-pack\";\n \t\tif (remote && remote->uploadpack)\n \t\t\tdata->uploadpack = remote->uploadpack;\n-\t\tdata->receivepack = \"git-receive-pack\";\n+\t\tdata->receivepack = \"git receive-pack\";\n \t\tif (remote && remote->receivepack)\n \t\t\tdata->receivepack = remote->receivepack;\n \t}\n-- \n1.5.3.6.2088.g8c260\n"},{"id":"61500","messageId":"fcaeb9bf0711300419i9cf70eo9f96e3a5e3f44585@mail.gmail.com","threadId":"11033","inReplyTo":"DB613F3E-85CC-4AF0-928C-4F4E4C8E9FB8@orakel.ntnu.no","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-11-30T12:19:50Z","receivedAt":"2007-11-30T12:19:50Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Nov 30, 2007 6:28 PM, Eyvind Bernhardsen\n wrote:\n> On 29. nov. 2007, at 23.36, Junio C Hamano wrote:\n>\n> [...]\n>\n> > If people are really serious about reducing the number of commands in\n> > the path, I would expect fixes and bugreports saying \"I am setting\n> > gitexecdir different from bindir in _my_ installation when I build\n> > git,\n> > and here are the things that does not work if I do so\". Within the\n> > span\n> > of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I\n> > do not think there was a single such report or patch, other than the\n> > message from Nguyen that started this thread.\n>\n> I'm setting gitexecdir different from bindir in my installation, and\n> here are the things that don't work:\n>\n> - When pushing to my system over ssh, git-receive-pack and git-upload-\n> pack are expected to be in $PATH. I resolved the problem by putting\n> symlinks in /usr/local/bin.\n>\n> I haven't seen any other problems, but then again, I only use git\n> plumbing commands and my own scripts.\n\nYou remind me my experience of making every external C-based command\nbuiltin. There is another case: git-merge. It calls something like\ngit-merge-$strategy.\n\n-- \nDuy\n"},{"id":"61504","messageId":"Pine.LNX.4.64.0711301334500.27959@racer.site","threadId":"11033","inReplyTo":"fcaeb9bf0711300419i9cf70eo9f96e3a5e3f44585@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T13:35:00Z","receivedAt":"2007-11-30T13:35:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Nov 2007, Nguyen Thai Ngoc Duy wrote:\n\n> On Nov 30, 2007 6:28 PM, Eyvind Bernhardsen\n> wrote:\n> > On 29. nov. 2007, at 23.36, Junio C Hamano wrote:\n> >\n> > [...]\n> >\n> > > If people are really serious about reducing the number of commands in\n> > > the path, I would expect fixes and bugreports saying \"I am setting\n> > > gitexecdir different from bindir in _my_ installation when I build\n> > > git,\n> > > and here are the things that does not work if I do so\". Within the\n> > > span\n> > > of more than 20 months (77cb17e9 introduced gitexecdir in Jan 2006), I\n> > > do not think there was a single such report or patch, other than the\n> > > message from Nguyen that started this thread.\n> >\n> > I'm setting gitexecdir different from bindir in my installation, and\n> > here are the things that don't work:\n> >\n> > - When pushing to my system over ssh, git-receive-pack and git-upload-\n> > pack are expected to be in $PATH. I resolved the problem by putting\n> > symlinks in /usr/local/bin.\n> >\n> > I haven't seen any other problems, but then again, I only use git\n> > plumbing commands and my own scripts.\n> \n> You remind me my experience of making every external C-based command\n> builtin. There is another case: git-merge. It calls something like\n> git-merge-$strategy.\n\nGood catch!\n\nCiao,\nDscho\n"},{"id":"61505","messageId":"20071130150948.GA22095@coredump.intra.peff.net","threadId":"11033","inReplyTo":"474FB938.3040209@op5.se","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T15:09:48Z","receivedAt":"2007-11-30T15:09:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 08:18:16AM +0100, Andreas Ericsson wrote:\n\n>> The only reason I have heard to remove them entirely is that Windows\n>> doesn't properly support hardlinks, which I addressed in my other mails\n>> (and to which I have seen no rebuttal).\n>>\n> It would provide a ui inconsistency between platforms. Several people\n> pointed that out. It's decidedly a Bad Thing.\n\nWhich, as I said, I have already addressed (and which Linus has also\nexpanded upon in this thread). Since those hardlinks would be hidden\nfrom users who did not go to some trouble to find them, there will not\nbe inconsistency problems. Scripts will have to either go to some effort\nto change their PATH, or simply use the correct form, and I expect them\nto do the latter.\n\n-Peff\n"},{"id":"61506","messageId":"20071130151223.GB22095@coredump.intra.peff.net","threadId":"11033","inReplyTo":"5E2A9E2B-8B9A-46B0-99D0-DB3798F10119@zib.de","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T15:12:23Z","receivedAt":"2007-11-30T15:12:23Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 06:51:35AM +0100, Steffen Prohaska wrote:\n\n> What will happen to gitk?\n>\n> Shouldn't it be included in the nice collection? gitk is\n> an essential command. Then, following your reasoning,\n> \"git \" should recommend it, no?\n>\n> Note, \"git gui\" already works. gitk would really be the last\n> git \"command\" that can't be accessed through \"git \"\n\nExcept for qgit, tig, etc. The only difference being that gitk actually\nships with git.\n\nBut I am not opposed to having some \"git foo\" form for gitk.\n\n-Peff\n"},{"id":"61507","messageId":"8aa486160711300728x70f591f1hf8884a78f2b15806@mail.gmail.com","threadId":"11033","inReplyTo":"20071130151223.GB22095@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-11-30T15:28:21Z","receivedAt":"2007-11-30T15:28:21Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On Nov 30, 2007 4:12 PM, Jeff King wrote:\n> On Fri, Nov 30, 2007 at 06:51:35AM +0100, Steffen Prohaska wrote:\n>\n> > What will happen to gitk?\n> >\n> > Shouldn't it be included in the nice collection? gitk is\n> > an essential command. Then, following your reasoning,\n> > \"git \" should recommend it, no?\n> >\n> > Note, \"git gui\" already works. gitk would really be the last\n> > git \"command\" that can't be accessed through \"git \"\n>\n> Except for qgit, tig, etc. The only difference being that gitk actually\n> ships with git.\n>\n> But I am not opposed to having some \"git foo\" form for gitk.\n\nIn mercurial \"hg view\" is actually an old version of gitk modified for hg.\n\nAnd as \"git view\" it could be added to the \"git help\" list.\n\nSanti\n"},{"id":"61508","messageId":"20071130152942.GA22489@coredump.intra.peff.net","threadId":"11033","inReplyTo":"8aa486160711300728x70f591f1hf8884a78f2b15806@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T15:29:43Z","receivedAt":"2007-11-30T15:29:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 04:28:21PM +0100, Santi Béjar wrote:\n\n> > But I am not opposed to having some \"git foo\" form for gitk.\n> \n> In mercurial \"hg view\" is actually an old version of gitk modified for hg.\n> \n> And as \"git view\" it could be added to the \"git help\" list.\n\nUnfortunately, there is already a \"gitview\" program similar to gitk,\nalthough it never made it out of contrib/.\n\n-Peff\n"},{"id":"61509","messageId":"alpine.LFD.0.9999.0711300745330.8458@woody.linux-foundation.org","threadId":"11033","inReplyTo":"20071130152942.GA22489@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-11-30T15:50:47Z","receivedAt":"2007-11-30T15:50:47Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 30 Nov 2007, Jeff King wrote:\n>\n> On Fri, Nov 30, 2007 at 04:28:21PM +0100, Santi Béjar wrote:\n> > > But I am not opposed to having some \"git foo\" form for gitk.\n> > \n> > In mercurial \"hg view\" is actually an old version of gitk modified for hg.\n> > \n> > And as \"git view\" it could be added to the \"git help\" list.\n> \n> Unfortunately, there is already a \"gitview\" program similar to gitk,\n> although it never made it out of contrib/.\n\nWell, different people will want different viewers *anyway* (ie some will \nprefer qgit etc), so how about making \"git view\" be something that \nliterally acts as a built-in alias that just defaults to running gitk (if \nfor no other reason than the fact that gitk is the one that ships with \ngit, and simply has most users).\n\nThere's a few other things that I think we could consider to be good \nbuilt-in aliases: things like \"git cat\" being an alias for \"git -p \ncat-file -p\" etc.\n\nThe only difference between a \"built-in alias\" and a \"built-in command\" \nwould be:\n - the alias has never even had the \"git-xyz\" format, and never will\n - the alias can be overridden by user aliases unlike \"real\" git commands\n\nHmm?\n\nThat way we can hide away gitk too (although I do suspect that we might as \nwell just leave gitk in the path - it's different in naming from all the \ngit-xyz commands anyway)\n\n\t\tLinus\n"},{"id":"61510","messageId":"20071130162257.GA22882@coredump.intra.peff.net","threadId":"11033","inReplyTo":"alpine.LFD.0.9999.0711300745330.8458@woody.linux-foundation.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T16:22:58Z","receivedAt":"2007-11-30T16:22:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 07:50:47AM -0800, Linus Torvalds wrote:\n\n> Well, different people will want different viewers *anyway* (ie some will \n> prefer qgit etc), so how about making \"git view\" be something that \n> literally acts as a built-in alias that just defaults to running gitk (if \n> for no other reason than the fact that gitk is the one that ships with \n> git, and simply has most users).\n\nI think that is a good idea, and here's a patch.\n\n-- >8 --\nSupport builtin aliases\n\nBuiltin aliases are \"default\" alias values that can be\noverridden by user-configured aliases.\n\nFor example, the first such alias is \"view\", an alias for\ngitk. A user with no further configuration can run\n\"git view\" to use gitk. However, they can also set the\nconfig option \"alias.view\" to \"!tig\" to run tig.\n---\n git.c | 9 +++++++++\n 1 files changed, 9 insertions(+), 0 deletions(-)\n\ndiff --git a/git.c b/git.c\nindex f220284..95296aa 100644\n--- a/git.c\n+++ b/git.c\n@@ -151,6 +151,13 @@ static int split_cmdline(char *cmdline, const char ***argv)\n \treturn count;\n }\n \n+static char *builtin_alias(const char *cmd)\n+{\n+\tif (!strcmp(cmd, \"view\"))\n+\t\treturn xstrdup(\"!gitk\");\n+\treturn NULL;\n+}\n+\n static int handle_alias(int *argcp, const char ***argv)\n {\n \tint nongit = 0, envchanged = 0, ret = 0, saved_errno = errno;\n@@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)\n \n \talias_command = (*argv)[0];\n \tgit_config(git_alias_config);\n+\tif (!alias_string)\n+\t\talias_string = builtin_alias(alias_command);\n \tif (alias_string) {\n \t\tif (alias_string[0] == '!') {\n \t\t\tif (*argcp > 1) {\n-- \n1.5.3.6.2064.g2e22f-dirty\n"},{"id":"61516","messageId":"Pine.LNX.4.64.0711301828050.27959@racer.site","threadId":"11033","inReplyTo":"20071130162257.GA22882@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T18:28:50Z","receivedAt":"2007-11-30T18:28:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Nov 2007, Jeff King wrote:\n\n> Support builtin aliases\n> \n> Builtin aliases are \"default\" alias values that can be\n> overridden by user-configured aliases.\n> \n> For example, the first such alias is \"view\", an alias for\n> gitk. A user with no further configuration can run\n> \"git view\" to use gitk. However, they can also set the\n> config option \"alias.view\" to \"!tig\" to run tig.\n> ---\n> git.c | 9 +++++++++\n> 1 files changed, 9 insertions(+), 0 deletions(-)\n> \n> diff --git a/git.c b/git.c\n> index f220284..95296aa 100644\n> --- a/git.c\n> +++ b/git.c\n> @@ -151,6 +151,13 @@ static int split_cmdline(char *cmdline, const char ***argv)\n> \treturn count;\n> }\n> \n> +static char *builtin_alias(const char *cmd)\n> +{\n> +\tif (!strcmp(cmd, \"view\"))\n> +\t\treturn xstrdup(\"!gitk\");\n> +\treturn NULL;\n> +}\n> +\n> static int handle_alias(int *argcp, const char ***argv)\n> {\n> \tint nongit = 0, envchanged = 0, ret = 0, saved_errno = errno;\n> @@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)\n> \n> \talias_command = (*argv)[0];\n> \tgit_config(git_alias_config);\n> +\tif (!alias_string)\n> +\t\talias_string = builtin_alias(alias_command);\n> \tif (alias_string) {\n> \t\tif (alias_string[0] == '!') {\n> \t\t\tif (*argcp > 1) {\n\nDidn't you mean to put this _before_ the git_config() call? As you wrote \nit, the \"soft\" alias overrides the user-specified one.\n\nCiao,\nDscho\n"},{"id":"61518","messageId":"20071130183755.GA29382@sigill.intra.peff.net","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711301828050.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T18:37:55Z","receivedAt":"2007-11-30T18:37:55Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 06:28:50PM +0000, Johannes Schindelin wrote:\n\n> > @@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)\n> > \n> > \talias_command = (*argv)[0];\n> > \tgit_config(git_alias_config);\n> > +\tif (!alias_string)\n> > +\t\talias_string = builtin_alias(alias_command);\n> > \tif (alias_string) {\n> > \t\tif (alias_string[0] == '!') {\n> > \t\t\tif (*argcp > 1) {\n> \n> Didn't you mean to put this _before_ the git_config() call? As you wrote \n> it, the \"soft\" alias overrides the user-specified one.\n\nNo. The \"if (!alias_string)\" means we only do the lookup if no user\nalias was found. Try it.\n\n-Peff\n"},{"id":"61521","messageId":"7vve7jqz92.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"20071130150948.GA22095@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-11-30T20:01:13Z","receivedAt":"2007-11-30T20:01:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Nov 30, 2007 at 08:18:16AM +0100, Andreas Ericsson wrote:\n> ...\n>> It would provide a ui inconsistency between platforms. Several people\n>> pointed that out. It's decidedly a Bad Thing.\n>\n> Which, as I said, I have already addressed (and which Linus has also\n> expanded upon in this thread). Since those hardlinks would be hidden\n> from users who did not go to some trouble to find them, there will not\n> be inconsistency problems.\n\nI already can see exchanges in the user community after such a change\nyou propose would happen:\n\n Newbie: Ay! why doesn't git-commit work anymore?\n\n Jeff: Stupid Junio and Linus decided that you should not use dash form\n but say \"git commit\" instead.\n\n Newbie: But my fingers are trained and I like the \"git-\"\n completion.\n\n Jeff: If you really like that, here is a hidden trick. Add\n /usr/libexec/git-core/ to your PATH.\n\n Newbie: Ah, that worked, thanks.\n\n A few days later...\n\n Newbie: Jeff, your trick does not work for my coworker. He also has\n the latest git. His installation does not even have that\n directory! What gives?\n\n Jeff: Ah, sorry, that trick works for some platforms but not others.\n\n Newbie: Stupid inconsistency. Who suggested that?\n"},{"id":"61525","messageId":"20071130212500.GB25946@coredump.intra.peff.net","threadId":"11033","inReplyTo":"7vve7jqz92.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T21:25:01Z","receivedAt":"2007-11-30T21:25:01Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 12:01:13PM -0800, Junio C Hamano wrote:\n\n> I already can see exchanges in the user community after such a change\n> you propose would happen:\n> [...]\n> Jeff: If you really like that, here is a hidden trick. Add\n> /usr/libexec/git-core/ to your PATH.\n\nWhat if I promise not to tell anyone? :)\n\nAnyway, I don't think it will be a problem. You think it might. But I\nsuspect neither of us has anything more than a gut feeling to argue\nwith. And now I have registered my complaint, so you can do what you\nthink is best.\n\nI can, of course, always make my own hardlinks (which is really the same\nthing, except the \"trick\" is slightly harder to perform and perhaps less\nsocially acceptable; OTOH, if such a trick is common, perhaps it means\ntaking away the dash forms wasn't such a good idea after all).\n\n> Newbie: Stupid inconsistency. Who suggested that?\n\nJeff [runs git-blame]: It must have been Junio! :)\n\n-Peff\n"},{"id":"61527","messageId":"Pine.LNX.4.64.0711302305300.27959@racer.site","threadId":"11033","inReplyTo":"20071130183755.GA29382@sigill.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T23:05:50Z","receivedAt":"2007-11-30T23:05:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Nov 2007, Jeff King wrote:\n\n> On Fri, Nov 30, 2007 at 06:28:50PM +0000, Johannes Schindelin wrote:\n> \n> > > @@ -162,6 +169,8 @@ static int handle_alias(int *argcp, const char ***argv)\n> > > \n> > > \talias_command = (*argv)[0];\n> > > \tgit_config(git_alias_config);\n> > > +\tif (!alias_string)\n> > > +\t\talias_string = builtin_alias(alias_command);\n> > > \tif (alias_string) {\n> > > \t\tif (alias_string[0] == '!') {\n> > > \t\t\tif (*argcp > 1) {\n> > \n> > Didn't you mean to put this _before_ the git_config() call? As you wrote \n> > it, the \"soft\" alias overrides the user-specified one.\n> \n> No. The \"if (!alias_string)\" means we only do the lookup if no user\n> alias was found. Try it.\n\nAh. To me, that was rather easy to miss, though...\n\nCiao,\nDscho\n"},{"id":"61528","messageId":"Pine.LNX.4.64.0711302306580.27959@racer.site","threadId":"11033","inReplyTo":"20071130212500.GB25946@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T23:10:23Z","receivedAt":"2007-11-30T23:10:23Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Nov 2007, Jeff King wrote:\n\n> On Fri, Nov 30, 2007 at 12:01:13PM -0800, Junio C Hamano wrote:\n> \n> > I already can see exchanges in the user community after such a change\n> > you propose would happen:\n> > [...]\n> > Jeff: If you really like that, here is a hidden trick. Add\n> > /usr/libexec/git-core/ to your PATH.\n> \n> What if I promise not to tell anyone? :)\n\nBy the same reasoning you can invade an unsuspecting country, saying that \neverybody will be better off afterwards. But the risk is high, not \nbecause of the probability, but because of the cost to pay if it does not \nwork out.\n\nReally, I'd rather have this be done right. So I am quite happy with \nJunio being \"girly\" (which I would have called cautious and nice-to-users, \nas well as considerate, though).\n\nIn the end I would be so much happier not to have hard links at all, \nand it seems that all the \"easy\" SCMs out there are quite well off without \nhard links, too.\n\nTo me, it is mighty annoying anybody brings up that \"144 commands\" \nargument Linus was referring to, and if there is _any_ way to shut up \nthose bikeshedders, I am all for it.\n\nBut if that is not possible, so be it.\n\nCiao,\nDscho\n"},{"id":"61529","messageId":"20071130232127.GA3169@sigill.intra.peff.net","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711302305300.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-11-30T23:21:27Z","receivedAt":"2007-11-30T23:21:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 11:05:50PM +0000, Johannes Schindelin wrote:\n\n> > > > \talias_command = (*argv)[0];\n> > > > \tgit_config(git_alias_config);\n> > > > +\tif (!alias_string)\n> > > > +\t\talias_string = builtin_alias(alias_command);\n> > > > \tif (alias_string) {\n> > > > \t\tif (alias_string[0] == '!') {\n> > > > \t\t\tif (*argcp > 1) {\n> > > \n> > > Didn't you mean to put this _before_ the git_config() call? As you wrote \n> > > it, the \"soft\" alias overrides the user-specified one.\n> > \n> > No. The \"if (!alias_string)\" means we only do the lookup if no user\n> > alias was found. Try it.\n> \n> Ah. To me, that was rather easy to miss, though...\n\nI don't particularly care if it is re-written as:\n\n alias_string = builtin_alias(alias_command);\n git_config(git_alias_config);\n\nwhich should be equivalent. I wrote it the original way to avoid doing\nthe O(n) search through builtin aliases when it was unnecessary, but\nobviously this isn't a performance critical code path.\n\n-Peff\n"},{"id":"61530","messageId":"Pine.LNX.4.64.0711302338350.27959@racer.site","threadId":"11033","inReplyTo":"20071130232127.GA3169@sigill.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-11-30T23:38:57Z","receivedAt":"2007-11-30T23:38:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Nov 2007, Jeff King wrote:\n\n> On Fri, Nov 30, 2007 at 11:05:50PM +0000, Johannes Schindelin wrote:\n> \n> > > > > \talias_command = (*argv)[0];\n> > > > > \tgit_config(git_alias_config);\n> > > > > +\tif (!alias_string)\n> > > > > +\t\talias_string = builtin_alias(alias_command);\n> > > > > \tif (alias_string) {\n> > > > > \t\tif (alias_string[0] == '!') {\n> > > > > \t\t\tif (*argcp > 1) {\n> > > > \n> > > > Didn't you mean to put this _before_ the git_config() call? As you wrote \n> > > > it, the \"soft\" alias overrides the user-specified one.\n> > > \n> > > No. The \"if (!alias_string)\" means we only do the lookup if no user\n> > > alias was found. Try it.\n> > \n> > Ah. To me, that was rather easy to miss, though...\n> \n> I don't particularly care if it is re-written as:\n> \n> alias_string = builtin_alias(alias_command);\n> git_config(git_alias_config);\n> \n> which should be equivalent. I wrote it the original way to avoid doing\n> the O(n) search through builtin aliases when it was unnecessary, but\n> obviously this isn't a performance critical code path.\n\nActually, I felt/feel quite dumb missing it.\n\nCiao,\nDscho\n"},{"id":"61541","messageId":"7vlk8f9m52.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711301207020.27959@racer.site","subject":"Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-01T02:36:25Z","receivedAt":"2007-12-01T02:36:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Since we plan to move the dash-form (git-) into an execdir, it\n> make sense to prepare our git protocol users for it.\n>\n> Noticed by Eyvind Bernhardsen.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n>\n> \tOn Fri, 30 Nov 2007, Eyvind Bernhardsen wrote:\n>\n> \t> - When pushing to my system over ssh, git-receive-pack and\n> \t> git-upload-pack are expected to be in $PATH. I resolved the \n> \t> problem by putting symlinks in /usr/local/bin.\n>\n> \tHow about this? (I only compile-tested it...)\n\nI only eyeball-tested it and looks Okay, but that does not assure us\nmuch ;-). Is this change easy to test using local transport?\n"},{"id":"61548","messageId":"7vbq9b87jb.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"20071130212500.GB25946@coredump.intra.peff.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-01T02:37:12Z","receivedAt":"2007-12-01T02:37:12Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I can, of course, always make my own hardlinks (which is really the same\n> thing, except the \"trick\" is slightly harder to perform and perhaps less\n> socially acceptable; OTOH, if such a trick is common, perhaps it means\n> taking away the dash forms wasn't such a good idea after all).\n>\n>> Newbie: Stupid inconsistency. Who suggested that?\n>\n> Jeff [runs git-blame]: It must have been Junio! :)\n\nYou found a bug in git-blame, then ;-). I think it should report Jeff.\n\nAs Windows ports need to have their own difference _anyway_, I\npersonally do not think it is a big deal if the Makefile I ship\ncontinues to install the dashed form in gitexecdir, and Windows ports\nomit the hardlinks if they feel copies are wasteful.\n\nHowever, that would introduce hard-to-track platform dependent bugs\n(e.g. \"git-receive-pack\" is asked for by \"git-send-pack\", but the other\nside does not have such a program anywhere). So my preference at this\npoint is to move things out of PATH first (without removing the\nhardlinks), deal with possible fallout from that move.\n\nAnd after things stablize, discuss to either remove the hardlinks from\nall installations, or to keep them in all installations. I do not think\n\"it's this way here but that way there\" is a good thing in general.\n\nWe do have \"git-foo.exe\" vs \"git-foo\" difference and there are some\nexisting code (most notably, help.c::list_commands_in_dir()) that need\nto be aware of it. Let's try not to make things any worse.\n"},{"id":"61558","messageId":"20071201041747.GC30725@coredump.intra.peff.net","threadId":"11033","inReplyTo":"7vbq9b87jb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-01T04:17:47Z","receivedAt":"2007-12-01T04:17:47Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 30, 2007 at 06:37:12PM -0800, Junio C Hamano wrote:\n\n> side does not have such a program anywhere). So my preference at this\n> point is to move things out of PATH first (without removing the\n> hardlinks), deal with possible fallout from that move.\n> \n> And after things stablize, discuss to either remove the hardlinks from\n> all installations, or to keep them in all installations. I do not think\n> \"it's this way here but that way there\" is a good thing in general.\n\nI think that it is a sensible course of action.\n\n-Peff\n"},{"id":"61571","messageId":"Pine.LNX.4.64.0712010959180.27959@racer.site","threadId":"11033","inReplyTo":"7vlk8f9m52.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-01T10:17:03Z","receivedAt":"2007-12-01T10:17:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 30 Nov 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Since we plan to move the dash-form (git-) into an execdir, it\n> > make sense to prepare our git protocol users for it.\n> >\n> > Noticed by Eyvind Bernhardsen.\n> >\n> > Signed-off-by: Johannes Schindelin \n> > ---\n> >\n> > \tOn Fri, 30 Nov 2007, Eyvind Bernhardsen wrote:\n> >\n> > \t> - When pushing to my system over ssh, git-receive-pack and\n> > \t> git-upload-pack are expected to be in $PATH. I resolved the \n> > \t> problem by putting symlinks in /usr/local/bin.\n> >\n> > \tHow about this? (I only compile-tested it...)\n> \n> I only eyeball-tested it and looks Okay, but that does not assure us\n> much ;-). Is this change easy to test using local transport?\n\nSeems like it breaks down with git-shell. But then, I think that we just \nhave to fix execv_git_cmd() to call builtins via \"git\" instead.\n\nCiao,\nDscho\n"},{"id":"61594","messageId":"7vzlwu43i4.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712010959180.27959@racer.site","subject":"Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-01T19:30:11Z","receivedAt":"2007-12-01T19:30:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> I only eyeball-tested it and looks Okay, but that does not assure us\n>> much ;-). Is this change easy to test using local transport?\n>\n> Seems like it breaks down with git-shell. But then, I think that we just \n> have to fix execv_git_cmd() to call builtins via \"git\" instead.\n\nSo in execv_git_cmd(), instead of doing the strbuf_addf(), we do\nsomething like this (and drop your patch)?\n\n---\n exec_cmd.c | 34 +++++++++++++---------------------\n 1 files changed, 13 insertions(+), 21 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 2d0a758..2920335 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -65,32 +65,24 @@ void setup_path(const char *cmd_path)\n \n int execv_git_cmd(const char **argv)\n {\n-\tstruct strbuf cmd;\n-\tconst char *tmp;\n-\n-\tstrbuf_init(&cmd, 0);\n-\tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n-\n-\t/*\n-\t * argv[0] must be the git command, but the argv array\n-\t * belongs to the caller, and may be reused in\n-\t * subsequent loop iterations. Save argv[0] and\n-\t * restore it on error.\n-\t */\n-\ttmp = argv[0];\n-\targv[0] = cmd.buf;\n-\n-\ttrace_argv_printf(argv, -1, \"trace: exec:\");\n+\tint i;\n+\tconst char **args;\n+\n+\tfor (i = 0; argv[i]; i++)\n+\t\t;\n+\targs = xcalloc(i + 1, sizeof(*args));\n+\tfor (i = 0; argv[i]; i++)\n+\t\targs[i+1] = argv[i];\n+\targs[0] = \"git\";\n+\targs[i+1] = NULL;\n+\ttrace_argv_printf(args, -1, \"trace: exec:\");\n \n \t/* execvp() can only ever return if it fails */\n-\texecvp(cmd.buf, (char **)argv);\n+\texecvp(args[0], (char **)args);\n \n \ttrace_printf(\"trace: exec failed: %s\\n\", strerror(errno));\n \n-\targv[0] = tmp;\n-\n-\tstrbuf_release(&cmd);\n-\n+\tfree(args);\n \treturn -1;\n }\n \n"},{"id":"61595","messageId":"7vve7i43ec.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"fcaeb9bf0711302234l32460a1fqbf9825fc8055f99d@mail.gmail.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-01T19:32:27Z","receivedAt":"2007-12-01T19:32:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On Nov 30, 2007 10:50 PM, Linus Torvalds wrote:\n>\n>> Well, different people will want different viewers *anyway* (ie some will\n>> prefer qgit etc), so how about making \"git view\" be something that\n>> literally acts as a built-in alias that just defaults to running gitk (if\n>> for no other reason than the fact that gitk is the one that ships with\n>> git, and simply has most users).\n>\n> We already have \"git show\", now we gonna get \"git view\", git trainers\n> may have hard time explaining this one shows you a particular object\n> while the other one shows you history. How about \"git lshistory\" (from\n> clearcase land) or git show --history?\n\nHeh, we have \"bisect visualize\". How about \"git visualize\"?\n"},{"id":"61600","messageId":"20071201212655.GA22349@coredump.intra.peff.net","threadId":"11033","inReplyTo":"7vve7i43ec.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-12-01T21:26:56Z","receivedAt":"2007-12-01T21:26:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 01, 2007 at 11:32:27AM -0800, Junio C Hamano wrote:\n\n> > We already have \"git show\", now we gonna get \"git view\", git trainers\n> > may have hard time explaining this one shows you a particular object\n> > while the other one shows you history. How about \"git lshistory\" (from\n> > clearcase land) or git show --history?\n> \n> Heh, we have \"bisect visualize\". How about \"git visualize\"?\n\nYes, in retrospect \"view\" is probably not the best. \"lshistory\" just\nlooks awful, and I think it's wrong for an option to \"git show\" to\nchange it from a terminal application into a GUI application.\n\n\"visualize\" is actually pretty good, except that it would be painful to\ntype. On the other hand, I will probably still just type \"gitk\". I\nactually think these sorts of aliases may be most useful for user-facing\nscripts to say \"and now show the dataset in the user's graphical history\nbrowser of choice.\"\n\n-Peff\n"},{"id":"61605","messageId":"Pine.LNX.4.64.0712012300440.27959@racer.site","threadId":"11033","inReplyTo":"7vzlwu43i4.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-01T23:03:38Z","receivedAt":"2007-12-01T23:03:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 1 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> I only eyeball-tested it and looks Okay, but that does not assure us\n> >> much ;-). Is this change easy to test using local transport?\n> >\n> > Seems like it breaks down with git-shell. But then, I think that we just \n> > have to fix execv_git_cmd() to call builtins via \"git\" instead.\n> \n> So in execv_git_cmd(), instead of doing the strbuf_addf(), we do\n> something like this (and drop your patch)?\n\nYou know what is really funny? I have this in my stash:\n\n-- snip --\n exec_cmd.c | 30 ++++++++++++------------------\n t/t0020-crlf.sh | 2 +-\n 2 files changed, 13 insertions(+), 19 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 2d0a758..7d022a2 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -65,31 +65,25 @@ void setup_path(const char *cmd_path)\n \n int execv_git_cmd(const char **argv)\n {\n-\tstruct strbuf cmd;\n-\tconst char *tmp;\n+\tint i;\n+\tchar **new_argv;\n \n-\tstrbuf_init(&cmd, 0);\n-\tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n+\tfor (i = 0; argv[i]; i++)\n+\t\t; /* do nothing */\n+\tnew_argv = xmalloc((i + 2) * sizeof(*new_argv));\n+\tnew_argv[0] = \"git\";\n+\tfor (i = 0; argv[i]; i++)\n+\t\tnew_argv[i + 1] = (char *)argv[i];\n+\tnew_argv[i] = NULL;\n \n-\t/*\n-\t * argv[0] must be the git command, but the argv array\n-\t * belongs to the caller, and may be reused in\n-\t * subsequent loop iterations. Save argv[0] and\n-\t * restore it on error.\n-\t */\n-\ttmp = argv[0];\n-\targv[0] = cmd.buf;\n-\n-\ttrace_argv_printf(argv, -1, \"trace: exec:\");\n+\ttrace_argv_printf((const char **)new_argv, -1, \"trace: exec:\");\n \n \t/* execvp() can only ever return if it fails */\n-\texecvp(cmd.buf, (char **)argv);\n+\texecvp(new_argv[0], new_argv);\n \n \ttrace_printf(\"trace: exec failed: %s\\n\", strerror(errno));\n \n-\targv[0] = tmp;\n-\n-\tstrbuf_release(&cmd);\n+\tfree(new_argv);\n \n \treturn -1;\n }\ndiff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh\nindex 62bc4bb..275379d 100755\n--- a/t/t0020-crlf.sh\n+++ b/t/t0020-crlf.sh\n@@ -36,7 +36,7 @@ test_expect_success setup '\n \n \tfor w in Some extra lines here; do echo $w; done >>one &&\n \tgit diff >patch.file &&\n-\tpatched=`git hash-object --stdin Will investigate right now,\n\nThe problem is that \"git \" will call execv_git_cmd() for \nnon-builtins, which in turn will execute \"git \", ... ad \ninfinitum.\n\nCiao,\nDscho\n"},{"id":"61608","messageId":"7vbq993lkp.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712012314190.27959@racer.site","subject":"Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-02T01:57:26Z","receivedAt":"2007-12-02T01:57:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sat, 1 Dec 2007, Johannes Schindelin wrote:\n>\n>> Will investigate right now,\n>\n> The problem is that \"git \" will call execv_git_cmd() for \n> non-builtins, which in turn will execute \"git \", ... ad \n> infinitum.\n\nOk, then the \".. then try the external ones\" in git.c needs to do the\nexecvp itself, which should not be a big deal.\n\nVery funny ;-).\n"},{"id":"61610","messageId":"Pine.LNX.4.64.0712020146240.27959@racer.site","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712012314190.27959@racer.site","subject":"[PATCH 0/3] Call builtin functions directly, was Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T02:52:52Z","receivedAt":"2007-12-02T02:52:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 1 Dec 2007, Johannes Schindelin wrote:\n\n> On Sat, 1 Dec 2007, Johannes Schindelin wrote:\n> \n> > Will investigate right now,\n> \n> The problem is that \"git \" will call execv_git_cmd() for \n> non-builtins, which in turn will execute \"git \", ... ad \n> infinitum.\n\nOkay, I bit the apple and tried to move the builtins into the library, and \nrename handle_internal_command into execv_git_builtin(), moving it into \nexec-cmd.c.\n\nBig mistake.\n\nWhy? Because there is at least one caller, git-bundle, which relies on \nexecv_git_cmd() _not_ reusing all those \"nice\" one-shot static variables, \nlike for example the object hashmap and the objects themselves.\n\nNow, it seems that we can get away for the moment with just introducing an \nobject release mechanism and calling that in execv_git_builtin() before \ncalling a builtin function, because the existing callers do not rely on \nmore than a cleanup of the objects.\n\nBut it is hairy, since it is such an essential part of git. And since I \nwas utterly tired while preparing this patch series. So I suggest maybe \nputting this into pu, but no further for the moment. I will use the \npatched git in the next days, though, to catch breakages (hopefully).\n\nCiao,\nDscho\n"},{"id":"61611","messageId":"Pine.LNX.4.64.0712020254120.27959@racer.site","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712020146240.27959@racer.site","subject":"[PATCH 1/3] Introduce release_all_objects()","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T02:54:27Z","receivedAt":"2007-12-02T02:54:27Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nThe new function release_all_objects() can be used to flush the object\ncache. This will be needed for the upcoming change in execv_git_cmd(),\nwhich should call the builtin functions directly instead of calling\nexecvp().\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tGuess how surprised I was when \"free(commit);\" would work the\n\tfirst time, but not the second...\n\n\tATM I use an ugly way to cope with the static \"nr\" variables\n\tin alloc.c: I just do not free() the last block.\n\n\tIt might be a better idea to refactor the (quite ugly) code in\n\talloc.c to have global structures a la\n\n\t\t#define BLOCKING 1024\n\n\t\tstruct object_block {\n\t\t\tsize_t struct_size;\n\t\t\tint nr;\n\t\t\t/* first (uint32_t *) is pointer to previous block */\n\t\t\tvoid *block;\n\t\t};\n\n\t\tstatic void *alloc_node(struct object_block *block)\n\t\t{\n\t\t\tif (!block || block->nr >= BLOCKING) {\n\t\t\t\tvoid *next = xmalloc(sizeof(void *)\n\t\t\t\t\t+ BLOCKING * block->struct_size);\n\t\t\t\t*(void **)next = block->block;\n\t\t\t\tblock->block = next;\n\t\t\t\tblock->nr = 0;\n\t\t\t}\n\t\t\treturn block->block + sizeof(void *)\n\t\t\t\t+ block->struct_size * block->nr++;\n\t\t}\n\n\t\tstatic void release_nodes(struct object_block *block)\n\t\t{\n\t\t\twhile (block->block) {\n\t\t\t\tvoid *previous = *(void **)block->block;\n\t\t\t\tfree(block->block);\n\t\t\t\tblock->block = previous;\n\t\t\t}\n\t\t\tblock->nr = 0; /* not strictly necessary */\n\t\t}\n\n\t\t#define DEFINE_ALLOCATOR(type)\t\t\t\t\\\n\t\tstatic object_block type##s = { sizeof(struct type) };\t\\\n\t\tstruct type *alloc_##type##_node(void)\t\t\t\\\n\t\t{\t\t\t\t\t\t\t\\\n\t\t\treturn alloc_node(&type##s);\t\t\t\\\n\t\t}\n\n\t\tDEFINE_ALLOCATOR(object)\n\t\tDEFINE_ALLOCATOR(blob)\n\t\tDEFINE_ALLOCATOR(tree)\n\t\tDEFINE_ALLOCATOR(commit)\n\t\tDEFINE_ALLOCATOR(tag)\n\n\tbut I am waaay too tired to brush this up, test it and submit it\n\t(hint, hint).\n\n alloc.c | 31 ++++++++++++++++++++++++++++++-\n blob.c | 3 +++\n blob.h | 1 +\n cache.h | 6 ++++++\n commit.c | 8 ++++++++\n commit.h | 2 ++\n object.c | 24 ++++++++++++++++++++++++\n object.h | 2 ++\n tag.c | 8 ++++++++\n tag.h | 2 ++\n tree.c | 6 ++++++\n tree.h | 1 +\n 12 files changed, 93 insertions(+), 1 deletions(-)\n\ndiff --git a/alloc.c b/alloc.c\nindex 216c23a..8c5e5e0 100644\n--- a/alloc.c\n+++ b/alloc.c\n@@ -20,6 +20,7 @@\n \n #define DEFINE_ALLOCATOR(name, type)\t\t\t\t\\\n static unsigned int name##_allocs;\t\t\t\t\\\n+static void *last_alloced_##name;\t\t\t\t\\\n void *alloc_##name##_node(void)\t\t\t\t\t\\\n {\t\t\t\t\t\t\t\t\\\n \tstatic int nr;\t\t\t\t\t\t\\\n@@ -28,13 +29,32 @@ void *alloc_##name##_node(void)\t\t\t\t\t\\\n \t\t\t\t\t\t\t\t\\\n \tif (!nr) {\t\t\t\t\t\t\\\n \t\tnr = BLOCKING;\t\t\t\t\t\\\n-\t\tblock = xmalloc(BLOCKING * sizeof(type));\t\\\n+\t\tstruct {\t\t\t\t\t\\\n+\t\t\tvoid *previous;\t\t\t\t\\\n+\t\t\ttype block[BLOCKING];\t\t\t\\\n+\t\t} *buf = xmalloc(sizeof(*buf));\t\t\t\\\n+\t\tbuf->previous = last_alloced_##name;\t\t\\\n+\t\tlast_alloced_##name = buf;\t\t\t\\\n+\t\tblock = buf->block;\t\t\t\t\\\n \t}\t\t\t\t\t\t\t\\\n \tnr--;\t\t\t\t\t\t\t\\\n \tname##_allocs++;\t\t\t\t\t\\\n \tret = block++;\t\t\t\t\t\t\\\n \tmemset(ret, 0, sizeof(type));\t\t\t\t\\\n \treturn ret;\t\t\t\t\t\t\\\n+}\t\t\t\t\t\t\t\t\\\n+\t\t\t\t\t\t\t\t\\\n+void release_all_##name##_nodes(void)\t\t\t\t\\\n+{\t\t\t\t\t\t\t\t\\\n+\tvoid *buf = last_alloced_##name;\t\t\t\\\n+\tif (!buf)\t\t\t\t\t\t\\\n+\t\treturn;\t\t\t\t\t\t\\\n+\tbuf = *(void **)buf;\t\t\t\t\t\\\n+\twhile (buf) {\t\t\t\t\t\t\\\n+\t\tvoid *next = *(void **)buf;\t\t\t\\\n+\t\tfree(buf);\t\t\t\t\t\\\n+\t\tbuf = next;\t\t\t\t\t\\\n+\t}\t\t\t\t\t\t\t\\\n }\n \n union any_object {\n@@ -74,3 +94,12 @@ void alloc_report(void)\n \tREPORT(commit);\n \tREPORT(tag);\n }\n+\n+void release_all_nodes(void)\n+{\n+\trelease_all_blob_nodes();\n+\trelease_all_tree_nodes();\n+\trelease_all_commit_nodes();\n+\trelease_all_tag_nodes();\n+\trelease_all_object_nodes();\n+}\ndiff --git a/blob.c b/blob.c\nindex bd7d078..63756e6 100644\n--- a/blob.c\n+++ b/blob.c\n@@ -18,6 +18,9 @@ struct blob *lookup_blob(const unsigned char *sha1)\n \treturn (struct blob *) obj;\n }\n \n+void release_blob(struct blob *blob) {\n+}\n+\n int parse_blob_buffer(struct blob *item, void *buffer, unsigned long size)\n {\n \titem->object.parsed = 1;\ndiff --git a/blob.h b/blob.h\nindex ea5d9e9..7560671 100644\n--- a/blob.h\n+++ b/blob.h\n@@ -10,6 +10,7 @@ struct blob {\n };\n \n struct blob *lookup_blob(const unsigned char *sha1);\n+void release_blob(struct blob *blob);\n \n int parse_blob_buffer(struct blob *item, void *buffer, unsigned long size);\n \ndiff --git a/cache.h b/cache.h\nindex 4e59646..cc50f1c 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -613,6 +613,12 @@ extern void *alloc_tree_node(void);\n extern void *alloc_commit_node(void);\n extern void *alloc_tag_node(void);\n extern void *alloc_object_node(void);\n+extern void release_all_blob_nodes(void);\n+extern void release_all_tree_nodes(void);\n+extern void release_all_commit_nodes(void);\n+extern void release_all_tag_nodes(void);\n+extern void release_all_object_nodes(void);\n+extern void release_all_nodes(void);\n extern void alloc_report(void);\n \n /* trace.c */\ndiff --git a/commit.c b/commit.c\nindex f074811..59c2236 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -48,6 +48,14 @@ struct commit *lookup_commit(const unsigned char *sha1)\n \treturn check_commit(obj, sha1, 0);\n }\n \n+void release_commit(struct commit *commit)\n+{\n+\tif (commit->parents)\n+\t\tfree_commit_list(commit->parents);\n+\tif (commit->buffer)\n+\t\tfree(commit->buffer);\n+}\n+\n static unsigned long parse_commit_date(const char *buf)\n {\n \tunsigned long date;\ndiff --git a/commit.h b/commit.h\nindex 10e2b5d..363b9fb 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -21,6 +21,7 @@ struct commit {\n \tchar *buffer;\n };\n \n+\n extern int save_commit_buffer;\n extern const char *commit_type;\n \n@@ -35,6 +36,7 @@ struct commit *lookup_commit(const unsigned char *sha1);\n struct commit *lookup_commit_reference(const unsigned char *sha1);\n struct commit *lookup_commit_reference_gently(const unsigned char *sha1,\n \t\t\t\t\t int quiet);\n+void release_commit(struct commit *commit);\n \n int parse_commit_buffer(struct commit *item, void *buffer, unsigned long size);\n \ndiff --git a/object.c b/object.c\nindex 16793d9..f217122 100644\n--- a/object.c\n+++ b/object.c\n@@ -192,6 +192,30 @@ struct object *parse_object(const unsigned char *sha1)\n \treturn NULL;\n }\n \n+void release_all_objects(void)\n+{\n+\tint i;\n+\tfor (i = 0; i < obj_hash_size; i++)\n+\t\tif (obj_hash[i]) {\n+\t\t\tswitch (obj_hash[i]->type) {\n+\t\t\tcase OBJ_BLOB:\n+\t\t\t\trelease_blob((struct blob *)obj_hash[i]);\n+\t\t\t\tbreak;\n+\t\t\tcase OBJ_COMMIT:\n+\t\t\t\trelease_commit((struct commit *)obj_hash[i]);\n+\t\t\t\tbreak;\n+\t\t\t/*case OBJ_TREE:\n+\t\t\t\trelease_tree((struct tree *)obj_hash[i]);\n+\t\t\t\tbreak;\n+\t\t\tcase OBJ_TAG:\n+\t\t\t\trelease_tag((struct tag *)obj_hash[i]);\n+\t\t\t\tbreak;*/\n+\t\t\t}\n+\t\t\tobj_hash[i] = NULL;\n+\t\t}\n+\trelease_all_nodes();\n+}\n+\n struct object_list *object_list_insert(struct object *item,\n \t\t\t\t struct object_list **list_p)\n {\ndiff --git a/object.h b/object.h\nindex 397bbfa..ad6184c 100644\n--- a/object.h\n+++ b/object.h\n@@ -44,6 +44,8 @@ extern unsigned int get_max_object_index(void);\n extern struct object *get_indexed_object(unsigned int);\n extern struct object_refs *lookup_object_refs(struct object *);\n \n+extern void release_all_objects(void);\n+\n /** Internal only **/\n struct object *lookup_object(const unsigned char *sha1);\n \ndiff --git a/tag.c b/tag.c\nindex f62bcdd..8bc6840 100644\n--- a/tag.c\n+++ b/tag.c\n@@ -33,6 +33,14 @@ struct tag *lookup_tag(const unsigned char *sha1)\n return (struct tag *) obj;\n }\n \n+void release_tag(struct tag *tag)\n+{\n+\tif (tag->tag)\n+\t\tfree(tag->tag);\n+\tif (tag->signature)\n+\t\tfree(tag->signature);\n+}\n+\n int parse_tag_buffer(struct tag *item, void *data, unsigned long size)\n {\n \tint typelen, taglen;\ndiff --git a/tag.h b/tag.h\nindex 7a0cb00..fbc6048 100644\n--- a/tag.h\n+++ b/tag.h\n@@ -12,6 +12,8 @@ struct tag {\n \tchar *signature; /* not actually implemented */\n };\n \n+void release_tag(struct tag *tag);\n+\n extern struct tag *lookup_tag(const unsigned char *sha1);\n extern int parse_tag_buffer(struct tag *item, void *data, unsigned long size);\n extern int parse_tag(struct tag *item);\ndiff --git a/tree.c b/tree.c\nindex 8c0819f..ee99bc6 100644\n--- a/tree.c\n+++ b/tree.c\n@@ -202,6 +202,12 @@ struct tree *lookup_tree(const unsigned char *sha1)\n \treturn (struct tree *) obj;\n }\n \n+void release_tree(struct tree *tree)\n+{\n+\tif (tree->buffer)\n+\t\tfree(tree->buffer);\n+}\n+\n /*\n * NOTE! Tree refs to external git repositories\n * (ie gitlinks) do not count as real references.\ndiff --git a/tree.h b/tree.h\nindex dd25c53..f8372a2 100644\n--- a/tree.h\n+++ b/tree.h\n@@ -12,6 +12,7 @@ struct tree {\n };\n \n struct tree *lookup_tree(const unsigned char *sha1);\n+void release_tree(struct tree *tree);\n \n int parse_tree_buffer(struct tree *item, void *buffer, unsigned long size);\n \n-- \n1.5.3.6.2112.ge2263\n"},{"id":"61612","messageId":"Pine.LNX.4.64.0712020254370.27959@racer.site","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712020146240.27959@racer.site","subject":"[PATCH 2/3] Include the objects needed for the builtin functions into libgit.a","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T02:54:47Z","receivedAt":"2007-12-02T02:54:47Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nFor the upcoming change in execv_git_cmd() to call builtin functions\ndirectly, it is necessary to be able to access the builtins, so\nmove the corresponding objects into libgit.a.\n\nSigned-off-by: Johannes Schindelin \n---\n Makefile | 14 +++++++++-----\n 1 files changed, 9 insertions(+), 5 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex f000a5e..f9a62eb 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -314,7 +314,8 @@ LIB_OBJS = \\\n \talloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \\\n \tcolor.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \\\n \tconvert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \\\n-\ttransport.o bundle.o walker.o parse-options.o\n+\ttransport.o bundle.o walker.o parse-options.o \\\n+\t$(BUILTIN_OBJS)\n \n BUILTIN_OBJS = \\\n \tbuiltin-add.o \\\n@@ -785,12 +786,12 @@ strip: $(PROGRAMS) git$X\n \t$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X\n \n git.o: git.c common-cmds.h GIT-CFLAGS\n-\t$(QUIET_CC)$(CC) -DGIT_VERSION='\"$(GIT_VERSION)\"' \\\n+\t$(QUIET_CC)$(CC) \\\n \t\t$(ALL_CFLAGS) -c $(filter %.c,$^)\n \n git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \\\n-\t\t$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)\n+\t\t$(ALL_LDFLAGS) $(LIBS)\n \n help.o: common-cmds.h\n \n@@ -894,7 +895,10 @@ git.o git.spec \\\n \t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<\n \n exec_cmd.o: exec_cmd.c GIT-CFLAGS\n-\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH=\"$(gitexecdir_SQ)\"' $<\n+\t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \\\n+\t\t-DGIT_EXEC_PATH='\"$(gitexecdir_SQ)\"' \\\n+\t\t-DGIT_VERSION='\"$(GIT_VERSION)\"' \\\n+\t\t$<\n builtin-init-db.o: builtin-init-db.c GIT-CFLAGS\n \t$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='\"$(template_dir_SQ)\"' $<\n \n@@ -920,7 +924,7 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)\n \t$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \\\n \t\t$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)\n \n-$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)\n+$(LIB_OBJS): $(LIB_H)\n $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)\n builtin-revert.o builtin-runstatus.o wt-status.o: wt-status.h\n \n-- \n1.5.3.6.2112.ge2263\n"},{"id":"61613","messageId":"Pine.LNX.4.64.0712020254540.27959@racer.site","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712020146240.27959@racer.site","subject":"[PATCH 3/3] Introduce execv_git_builtin() and use it","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T02:55:08Z","receivedAt":"2007-12-02T02:55:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nYou can call execv_git_builtin() to execute a builtin command. This\nfunction is a reborn handle_internal_command() from git.c, and has the\nsemantics of execv_git_cmd(), i.e. it exits with the exit code of the\nbuiltin if there is a matching builtin, but it avoids the real\nexecvp() call.\n\nThis function calls release_all_objects() and discard_cache() to start\nfrom a clean slate (this, along with the calculation of argc, is the\nonly difference from a straight code move).\n\nThe test suite passes, which at least does not contradict the\nhypothesis that this is good enough. However, it might be\nnecessary to de-initialize more global variables.\n\nThe function execv_git_cmd() and git.c's main() function were changed\nto take advantage of execv_git_builtin().\n\nSigned-off-by: Johannes Schindelin \n---\n exec_cmd.c | 178 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n exec_cmd.h | 1 +\n git.c | 172 +---------------------------------------------------------\n 3 files changed, 180 insertions(+), 171 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 2d0a758..ac21181 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -1,6 +1,8 @@\n #include \"cache.h\"\n #include \"exec_cmd.h\"\n #include \"quote.h\"\n+#include \"builtin.h\"\n+#include \"object.h\"\n #define MAX_ARGS\t32\n \n extern char **environ;\n@@ -63,11 +65,187 @@ void setup_path(const char *cmd_path)\n \tstrbuf_release(&new_path);\n }\n \n+const char git_usage_string[] =\n+\t\"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]\";\n+\n+const char git_version_string[] = GIT_VERSION;\n+\n+#define RUN_SETUP\t(1<<0)\n+#define USE_PAGER\t(1<<1)\n+/*\n+ * require working tree to be present -- anything uses this needs\n+ * RUN_SETUP for reading from the configuration file.\n+ */\n+#define NEED_WORK_TREE\t(1<<2)\n+\n+struct cmd_struct {\n+\tconst char *cmd;\n+\tint (*fn)(int, const char **, const char *);\n+\tint option;\n+};\n+\n+static int run_command(struct cmd_struct *p, int argc, const char **argv)\n+{\n+\tint status;\n+\tstruct stat st;\n+\tconst char *prefix;\n+\n+\tprefix = NULL;\n+\tif (p->option & RUN_SETUP)\n+\t\tprefix = setup_git_directory();\n+\tif (p->option & USE_PAGER)\n+\t\tsetup_pager();\n+\tif (p->option & NEED_WORK_TREE)\n+\t\tsetup_work_tree();\n+\n+\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n+\n+\tstatus = p->fn(argc, argv, prefix);\n+\tif (status)\n+\t\treturn status & 0xff;\n+\n+\t/* Somebody closed stdout? */\n+\tif (fstat(fileno(stdout), &st))\n+\t\treturn 0;\n+\t/* Ignore write errors for pipes and sockets.. */\n+\tif (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))\n+\t\treturn 0;\n+\n+\t/* Check for ENOSPC and EIO errors.. */\n+\tif (fflush(stdout))\n+\t\tdie(\"write failure on standard output: %s\", strerror(errno));\n+\tif (ferror(stdout))\n+\t\tdie(\"unknown write failure on standard output\");\n+\tif (fclose(stdout))\n+\t\tdie(\"close failed on standard output: %s\", strerror(errno));\n+\treturn 0;\n+}\n+\n+int execv_git_builtin(const char **argv)\n+{\n+\tconst char *cmd = argv[0];\n+\tstatic struct cmd_struct commands[] = {\n+\t\t{ \"add\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"annotate\", cmd_annotate, RUN_SETUP },\n+\t\t{ \"apply\", cmd_apply },\n+\t\t{ \"archive\", cmd_archive },\n+\t\t{ \"blame\", cmd_blame, RUN_SETUP },\n+\t\t{ \"branch\", cmd_branch, RUN_SETUP },\n+\t\t{ \"bundle\", cmd_bundle },\n+\t\t{ \"cat-file\", cmd_cat_file, RUN_SETUP },\n+\t\t{ \"checkout-index\", cmd_checkout_index,\n+\t\t\tRUN_SETUP | NEED_WORK_TREE},\n+\t\t{ \"check-ref-format\", cmd_check_ref_format },\n+\t\t{ \"check-attr\", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"cherry\", cmd_cherry, RUN_SETUP },\n+\t\t{ \"cherry-pick\", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"clean\", cmd_clean, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"commit\", cmd_commit, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"commit-tree\", cmd_commit_tree, RUN_SETUP },\n+\t\t{ \"config\", cmd_config },\n+\t\t{ \"count-objects\", cmd_count_objects, RUN_SETUP },\n+\t\t{ \"describe\", cmd_describe, RUN_SETUP },\n+\t\t{ \"diff\", cmd_diff },\n+\t\t{ \"diff-files\", cmd_diff_files },\n+\t\t{ \"diff-index\", cmd_diff_index, RUN_SETUP },\n+\t\t{ \"diff-tree\", cmd_diff_tree, RUN_SETUP },\n+\t\t{ \"fast-export\", cmd_fast_export, RUN_SETUP },\n+\t\t{ \"fetch\", cmd_fetch, RUN_SETUP },\n+\t\t{ \"fetch-pack\", cmd_fetch_pack, RUN_SETUP },\n+\t\t{ \"fetch--tool\", cmd_fetch__tool, RUN_SETUP },\n+\t\t{ \"fmt\", cmd_fmt },\n+\t\t{ \"fmt-merge-msg\", cmd_fmt_merge_msg, RUN_SETUP },\n+\t\t{ \"for-each-ref\", cmd_for_each_ref, RUN_SETUP },\n+\t\t{ \"format-patch\", cmd_format_patch, RUN_SETUP },\n+\t\t{ \"fsck\", cmd_fsck, RUN_SETUP },\n+\t\t{ \"fsck-objects\", cmd_fsck, RUN_SETUP },\n+\t\t{ \"gc\", cmd_gc, RUN_SETUP },\n+\t\t{ \"get-tar-commit-id\", cmd_get_tar_commit_id },\n+\t\t{ \"grep\", cmd_grep, RUN_SETUP | USE_PAGER },\n+\t\t{ \"help\", cmd_help },\n+#ifndef NO_CURL\n+\t\t{ \"http-fetch\", cmd_http_fetch, RUN_SETUP },\n+#endif\n+\t\t{ \"init\", cmd_init_db },\n+\t\t{ \"init-db\", cmd_init_db },\n+\t\t{ \"log\", cmd_log, RUN_SETUP | USE_PAGER },\n+\t\t{ \"ls-files\", cmd_ls_files, RUN_SETUP },\n+\t\t{ \"ls-tree\", cmd_ls_tree, RUN_SETUP },\n+\t\t{ \"ls-remote\", cmd_ls_remote },\n+\t\t{ \"mailinfo\", cmd_mailinfo },\n+\t\t{ \"mailsplit\", cmd_mailsplit },\n+\t\t{ \"merge-base\", cmd_merge_base, RUN_SETUP },\n+\t\t{ \"merge-file\", cmd_merge_file },\n+\t\t{ \"merge-ours\", cmd_merge_ours, RUN_SETUP },\n+\t\t{ \"mv\", cmd_mv, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"name-rev\", cmd_name_rev, RUN_SETUP },\n+\t\t{ \"pack-objects\", cmd_pack_objects, RUN_SETUP },\n+\t\t{ \"peek-remote\", cmd_ls_remote },\n+\t\t{ \"pickaxe\", cmd_blame, RUN_SETUP },\n+\t\t{ \"prune\", cmd_prune, RUN_SETUP },\n+\t\t{ \"prune-packed\", cmd_prune_packed, RUN_SETUP },\n+\t\t{ \"push\", cmd_push, RUN_SETUP },\n+\t\t{ \"read-tree\", cmd_read_tree, RUN_SETUP },\n+\t\t{ \"reflog\", cmd_reflog, RUN_SETUP },\n+\t\t{ \"repo-config\", cmd_config },\n+\t\t{ \"rerere\", cmd_rerere, RUN_SETUP },\n+\t\t{ \"reset\", cmd_reset, RUN_SETUP },\n+\t\t{ \"rev-list\", cmd_rev_list, RUN_SETUP },\n+\t\t{ \"rev-parse\", cmd_rev_parse },\n+\t\t{ \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"rm\", cmd_rm, RUN_SETUP },\n+\t\t{ \"send-pack\", cmd_send_pack, RUN_SETUP },\n+\t\t{ \"shortlog\", cmd_shortlog, RUN_SETUP | USE_PAGER },\n+\t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n+\t\t{ \"show\", cmd_show, RUN_SETUP | USE_PAGER },\n+\t\t{ \"status\", cmd_status, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"stripspace\", cmd_stripspace },\n+\t\t{ \"symbolic-ref\", cmd_symbolic_ref, RUN_SETUP },\n+\t\t{ \"tag\", cmd_tag, RUN_SETUP },\n+\t\t{ \"tar-tree\", cmd_tar_tree },\n+\t\t{ \"unpack-objects\", cmd_unpack_objects, RUN_SETUP },\n+\t\t{ \"update-index\", cmd_update_index, RUN_SETUP },\n+\t\t{ \"update-ref\", cmd_update_ref, RUN_SETUP },\n+\t\t{ \"upload-archive\", cmd_upload_archive },\n+\t\t{ \"verify-tag\", cmd_verify_tag, RUN_SETUP },\n+\t\t{ \"version\", cmd_version },\n+\t\t{ \"whatchanged\", cmd_whatchanged, RUN_SETUP | USE_PAGER },\n+\t\t{ \"write-tree\", cmd_write_tree, RUN_SETUP },\n+\t\t{ \"verify-pack\", cmd_verify_pack },\n+\t\t{ \"show-ref\", cmd_show_ref, RUN_SETUP },\n+\t\t{ \"pack-refs\", cmd_pack_refs, RUN_SETUP },\n+\t};\n+\tint i;\n+\n+\t/* Turn \"git cmd --help\" into \"git help cmd\" */\n+\tif (argv[0] && argv[1] && !strcmp(argv[1], \"--help\")) {\n+\t\targv[1] = argv[0];\n+\t\targv[0] = cmd = \"help\";\n+\t}\n+\n+\tfor (i = 0; i < ARRAY_SIZE(commands); i++) {\n+\t\tint argc;\n+\t\tstruct cmd_struct *p = commands+i;\n+\t\tif (strcmp(p->cmd, cmd))\n+\t\t\tcontinue;\n+\t\trelease_all_objects();\n+\t\tdiscard_cache();\n+\t\tfor (argc = 0; argv[argc]; argc++)\n+\t\t\t; /* do nothing */\n+\t\texit(run_command(p, argc, argv));\n+\t}\n+\treturn -1;\n+}\n+\n int execv_git_cmd(const char **argv)\n {\n \tstruct strbuf cmd;\n \tconst char *tmp;\n \n+\t/* Try builtin first... */\n+\texecv_git_builtin(argv);\n+\n+\t/* ... and then external commands */\n \tstrbuf_init(&cmd, 0);\n \tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n \ndiff --git a/exec_cmd.h b/exec_cmd.h\nindex a892355..bb15425 100644\n--- a/exec_cmd.h\n+++ b/exec_cmd.h\n@@ -4,6 +4,7 @@\n extern void git_set_argv_exec_path(const char *exec_path);\n extern const char* git_exec_path(void);\n extern void setup_path(const char *);\n+extern int execv_git_builtin(const char **argv); /* NULL terminated */\n extern int execv_git_cmd(const char **argv); /* NULL terminated */\n extern int execl_git_cmd(const char *cmd, ...);\n \ndiff --git a/git.c b/git.c\nindex 38b01ca..1523c4a 100644\n--- a/git.c\n+++ b/git.c\n@@ -3,9 +3,6 @@\n #include \"cache.h\"\n #include \"quote.h\"\n \n-const char git_usage_string[] =\n-\t\"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]\";\n-\n static int handle_options(const char*** argv, int* argc, int* envchanged)\n {\n \tint handled = 0;\n@@ -231,169 +228,6 @@ static int handle_alias(int *argcp, const char ***argv)\n \treturn ret;\n }\n \n-const char git_version_string[] = GIT_VERSION;\n-\n-#define RUN_SETUP\t(1<<0)\n-#define USE_PAGER\t(1<<1)\n-/*\n- * require working tree to be present -- anything uses this needs\n- * RUN_SETUP for reading from the configuration file.\n- */\n-#define NEED_WORK_TREE\t(1<<2)\n-\n-struct cmd_struct {\n-\tconst char *cmd;\n-\tint (*fn)(int, const char **, const char *);\n-\tint option;\n-};\n-\n-static int run_command(struct cmd_struct *p, int argc, const char **argv)\n-{\n-\tint status;\n-\tstruct stat st;\n-\tconst char *prefix;\n-\n-\tprefix = NULL;\n-\tif (p->option & RUN_SETUP)\n-\t\tprefix = setup_git_directory();\n-\tif (p->option & USE_PAGER)\n-\t\tsetup_pager();\n-\tif (p->option & NEED_WORK_TREE)\n-\t\tsetup_work_tree();\n-\n-\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n-\n-\tstatus = p->fn(argc, argv, prefix);\n-\tif (status)\n-\t\treturn status & 0xff;\n-\n-\t/* Somebody closed stdout? */\n-\tif (fstat(fileno(stdout), &st))\n-\t\treturn 0;\n-\t/* Ignore write errors for pipes and sockets.. */\n-\tif (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))\n-\t\treturn 0;\n-\n-\t/* Check for ENOSPC and EIO errors.. */\n-\tif (fflush(stdout))\n-\t\tdie(\"write failure on standard output: %s\", strerror(errno));\n-\tif (ferror(stdout))\n-\t\tdie(\"unknown write failure on standard output\");\n-\tif (fclose(stdout))\n-\t\tdie(\"close failed on standard output: %s\", strerror(errno));\n-\treturn 0;\n-}\n-\n-static void handle_internal_command(int argc, const char **argv)\n-{\n-\tconst char *cmd = argv[0];\n-\tstatic struct cmd_struct commands[] = {\n-\t\t{ \"add\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"annotate\", cmd_annotate, RUN_SETUP },\n-\t\t{ \"apply\", cmd_apply },\n-\t\t{ \"archive\", cmd_archive },\n-\t\t{ \"blame\", cmd_blame, RUN_SETUP },\n-\t\t{ \"branch\", cmd_branch, RUN_SETUP },\n-\t\t{ \"bundle\", cmd_bundle },\n-\t\t{ \"cat-file\", cmd_cat_file, RUN_SETUP },\n-\t\t{ \"checkout-index\", cmd_checkout_index,\n-\t\t\tRUN_SETUP | NEED_WORK_TREE},\n-\t\t{ \"check-ref-format\", cmd_check_ref_format },\n-\t\t{ \"check-attr\", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"cherry\", cmd_cherry, RUN_SETUP },\n-\t\t{ \"cherry-pick\", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"clean\", cmd_clean, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"commit\", cmd_commit, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"commit-tree\", cmd_commit_tree, RUN_SETUP },\n-\t\t{ \"config\", cmd_config },\n-\t\t{ \"count-objects\", cmd_count_objects, RUN_SETUP },\n-\t\t{ \"describe\", cmd_describe, RUN_SETUP },\n-\t\t{ \"diff\", cmd_diff },\n-\t\t{ \"diff-files\", cmd_diff_files },\n-\t\t{ \"diff-index\", cmd_diff_index, RUN_SETUP },\n-\t\t{ \"diff-tree\", cmd_diff_tree, RUN_SETUP },\n-\t\t{ \"fast-export\", cmd_fast_export, RUN_SETUP },\n-\t\t{ \"fetch\", cmd_fetch, RUN_SETUP },\n-\t\t{ \"fetch-pack\", cmd_fetch_pack, RUN_SETUP },\n-\t\t{ \"fetch--tool\", cmd_fetch__tool, RUN_SETUP },\n-\t\t{ \"fmt\", cmd_fmt },\n-\t\t{ \"fmt-merge-msg\", cmd_fmt_merge_msg, RUN_SETUP },\n-\t\t{ \"for-each-ref\", cmd_for_each_ref, RUN_SETUP },\n-\t\t{ \"format-patch\", cmd_format_patch, RUN_SETUP },\n-\t\t{ \"fsck\", cmd_fsck, RUN_SETUP },\n-\t\t{ \"fsck-objects\", cmd_fsck, RUN_SETUP },\n-\t\t{ \"gc\", cmd_gc, RUN_SETUP },\n-\t\t{ \"get-tar-commit-id\", cmd_get_tar_commit_id },\n-\t\t{ \"grep\", cmd_grep, RUN_SETUP | USE_PAGER },\n-\t\t{ \"help\", cmd_help },\n-#ifndef NO_CURL\n-\t\t{ \"http-fetch\", cmd_http_fetch, RUN_SETUP },\n-#endif\n-\t\t{ \"init\", cmd_init_db },\n-\t\t{ \"init-db\", cmd_init_db },\n-\t\t{ \"log\", cmd_log, RUN_SETUP | USE_PAGER },\n-\t\t{ \"ls-files\", cmd_ls_files, RUN_SETUP },\n-\t\t{ \"ls-tree\", cmd_ls_tree, RUN_SETUP },\n-\t\t{ \"ls-remote\", cmd_ls_remote },\n-\t\t{ \"mailinfo\", cmd_mailinfo },\n-\t\t{ \"mailsplit\", cmd_mailsplit },\n-\t\t{ \"merge-base\", cmd_merge_base, RUN_SETUP },\n-\t\t{ \"merge-file\", cmd_merge_file },\n-\t\t{ \"merge-ours\", cmd_merge_ours, RUN_SETUP },\n-\t\t{ \"mv\", cmd_mv, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"name-rev\", cmd_name_rev, RUN_SETUP },\n-\t\t{ \"pack-objects\", cmd_pack_objects, RUN_SETUP },\n-\t\t{ \"peek-remote\", cmd_ls_remote },\n-\t\t{ \"pickaxe\", cmd_blame, RUN_SETUP },\n-\t\t{ \"prune\", cmd_prune, RUN_SETUP },\n-\t\t{ \"prune-packed\", cmd_prune_packed, RUN_SETUP },\n-\t\t{ \"push\", cmd_push, RUN_SETUP },\n-\t\t{ \"read-tree\", cmd_read_tree, RUN_SETUP },\n-\t\t{ \"reflog\", cmd_reflog, RUN_SETUP },\n-\t\t{ \"repo-config\", cmd_config },\n-\t\t{ \"rerere\", cmd_rerere, RUN_SETUP },\n-\t\t{ \"reset\", cmd_reset, RUN_SETUP },\n-\t\t{ \"rev-list\", cmd_rev_list, RUN_SETUP },\n-\t\t{ \"rev-parse\", cmd_rev_parse },\n-\t\t{ \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"rm\", cmd_rm, RUN_SETUP },\n-\t\t{ \"send-pack\", cmd_send_pack, RUN_SETUP },\n-\t\t{ \"shortlog\", cmd_shortlog, RUN_SETUP | USE_PAGER },\n-\t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n-\t\t{ \"show\", cmd_show, RUN_SETUP | USE_PAGER },\n-\t\t{ \"status\", cmd_status, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"stripspace\", cmd_stripspace },\n-\t\t{ \"symbolic-ref\", cmd_symbolic_ref, RUN_SETUP },\n-\t\t{ \"tag\", cmd_tag, RUN_SETUP },\n-\t\t{ \"tar-tree\", cmd_tar_tree },\n-\t\t{ \"unpack-objects\", cmd_unpack_objects, RUN_SETUP },\n-\t\t{ \"update-index\", cmd_update_index, RUN_SETUP },\n-\t\t{ \"update-ref\", cmd_update_ref, RUN_SETUP },\n-\t\t{ \"upload-archive\", cmd_upload_archive },\n-\t\t{ \"verify-tag\", cmd_verify_tag, RUN_SETUP },\n-\t\t{ \"version\", cmd_version },\n-\t\t{ \"whatchanged\", cmd_whatchanged, RUN_SETUP | USE_PAGER },\n-\t\t{ \"write-tree\", cmd_write_tree, RUN_SETUP },\n-\t\t{ \"verify-pack\", cmd_verify_pack },\n-\t\t{ \"show-ref\", cmd_show_ref, RUN_SETUP },\n-\t\t{ \"pack-refs\", cmd_pack_refs, RUN_SETUP },\n-\t};\n-\tint i;\n-\n-\t/* Turn \"git cmd --help\" into \"git help cmd\" */\n-\tif (argc > 1 && !strcmp(argv[1], \"--help\")) {\n-\t\targv[1] = argv[0];\n-\t\targv[0] = cmd = \"help\";\n-\t}\n-\n-\tfor (i = 0; i < ARRAY_SIZE(commands); i++) {\n-\t\tstruct cmd_struct *p = commands+i;\n-\t\tif (strcmp(p->cmd, cmd))\n-\t\t\tcontinue;\n-\t\texit(run_command(p, argc, argv));\n-\t}\n-}\n-\n int main(int argc, const char **argv)\n {\n \tconst char *cmd = argv[0] ? argv[0] : \"git-help\";\n@@ -425,7 +259,7 @@ int main(int argc, const char **argv)\n \tif (!prefixcmp(cmd, \"git-\")) {\n \t\tcmd += 4;\n \t\targv[0] = cmd;\n-\t\thandle_internal_command(argc, argv);\n+\t\texecv_git_builtin(argv);\n \t\tdie(\"cannot handle %s internally\", cmd);\n \t}\n \n@@ -453,10 +287,6 @@ int main(int argc, const char **argv)\n \tsetup_path(cmd_path);\n \n \twhile (1) {\n-\t\t/* See if it's an internal command */\n-\t\thandle_internal_command(argc, argv);\n-\n-\t\t/* .. then try the external ones */\n \t\texecv_git_cmd(argv);\n \n \t\t/* It could be an alias -- this works around the insanity\n-- \n1.5.3.6.2112.ge2263\n"},{"id":"61614","messageId":"Pine.LNX.4.64.0712020303190.27959@racer.site","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712020254540.27959@racer.site","subject":"Re: [PATCH 3/3] Introduce execv_git_builtin() and use it","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T03:04:18Z","receivedAt":"2007-12-02T03:04:18Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Dec 2007, Johannes Schindelin wrote:\n\n> +\t\t{ \"fmt\", cmd_fmt },\n\nAh, well. This slipped in by mistake. Will resend in a few minutes.\n\nCiao,\nDscho\n"},{"id":"61615","messageId":"Pine.LNX.4.64.0712020310470.27959@racer.site","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712020303190.27959@racer.site","subject":"[REPLACEMENT PATCH 3/3] Introduce execv_git_builtin() and use it","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T03:16:13Z","receivedAt":"2007-12-02T03:16:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nYou can call execv_git_builtin() to execute a builtin command. This \nfunction is a reborn handle_internal_command() from git.c, and has the \nsemantics of execv_git_cmd(), i.e. it exits with the exit code of the \nbuiltin if there is a matching builtin, but it avoids the real execvp() \ncall.\n\nThis function calls release_all_objects() and discard_cache() to start \nfrom a clean slate (this, along with the calculation of argc, is the only \ndifference from a straight code move).\n\nThe test suite passes, which at least does not contradict the hypothesis \nthat this is good enough. However, it might be necessary to de-initialize \nmore global variables.\n\nThe function execv_git_cmd() and git.c's main() function were changed to \ntake advantage of execv_git_builtin().\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Sun, 2 Dec 2007, Johannes Schindelin wrote:\n\n\t> Hi,\n\t> \n\t> On Sun, 2 Dec 2007, Johannes Schindelin wrote:\n\t> \n\t> > +\t\t{ \"fmt\", cmd_fmt },\n\t> \n\t> Ah, well. This slipped in by mistake. Will resend in a few \n\t> minutes.\n\n\tHere we go.\n\n exec_cmd.c | 176 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++\n exec_cmd.h | 1 +\n git.c | 170 +---------------------------------------------------------\n 3 files changed, 178 insertions(+), 169 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 2d0a758..745b951 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -1,6 +1,8 @@\n #include \"cache.h\"\n #include \"exec_cmd.h\"\n #include \"quote.h\"\n+#include \"builtin.h\"\n+#include \"object.h\"\n #define MAX_ARGS\t32\n \n extern char **environ;\n@@ -63,11 +65,185 @@ void setup_path(const char *cmd_path)\n \tstrbuf_release(&new_path);\n }\n \n+const char git_usage_string[] =\n+\t\"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]\";\n+\n+const char git_version_string[] = GIT_VERSION;\n+\n+#define RUN_SETUP\t(1<<0)\n+#define USE_PAGER\t(1<<1)\n+/*\n+ * require working tree to be present -- anything uses this needs\n+ * RUN_SETUP for reading from the configuration file.\n+ */\n+#define NEED_WORK_TREE\t(1<<2)\n+\n+struct cmd_struct {\n+\tconst char *cmd;\n+\tint (*fn)(int, const char **, const char *);\n+\tint option;\n+};\n+\n+static int run_command(struct cmd_struct *p, int argc, const char **argv)\n+{\n+\tint status;\n+\tstruct stat st;\n+\tconst char *prefix;\n+\n+\tprefix = NULL;\n+\tif (p->option & RUN_SETUP)\n+\t\tprefix = setup_git_directory();\n+\tif (p->option & USE_PAGER)\n+\t\tsetup_pager();\n+\tif (p->option & NEED_WORK_TREE)\n+\t\tsetup_work_tree();\n+\n+\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n+\n+\tstatus = p->fn(argc, argv, prefix);\n+\tif (status)\n+\t\treturn status & 0xff;\n+\n+\t/* Somebody closed stdout? */\n+\tif (fstat(fileno(stdout), &st))\n+\t\treturn 0;\n+\t/* Ignore write errors for pipes and sockets.. */\n+\tif (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))\n+\t\treturn 0;\n+\n+\t/* Check for ENOSPC and EIO errors.. */\n+\tif (fflush(stdout))\n+\t\tdie(\"write failure on standard output: %s\", strerror(errno));\n+\tif (ferror(stdout))\n+\t\tdie(\"unknown write failure on standard output\");\n+\tif (fclose(stdout))\n+\t\tdie(\"close failed on standard output: %s\", strerror(errno));\n+\treturn 0;\n+}\n+\n+int execv_git_builtin(const char **argv)\n+{\n+\tconst char *cmd = argv[0];\n+\tstatic struct cmd_struct commands[] = {\n+\t\t{ \"add\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"annotate\", cmd_annotate, RUN_SETUP },\n+\t\t{ \"apply\", cmd_apply },\n+\t\t{ \"archive\", cmd_archive },\n+\t\t{ \"blame\", cmd_blame, RUN_SETUP },\n+\t\t{ \"branch\", cmd_branch, RUN_SETUP },\n+\t\t{ \"bundle\", cmd_bundle },\n+\t\t{ \"cat-file\", cmd_cat_file, RUN_SETUP },\n+\t\t{ \"checkout-index\", cmd_checkout_index,\n+\t\t\tRUN_SETUP | NEED_WORK_TREE},\n+\t\t{ \"check-ref-format\", cmd_check_ref_format },\n+\t\t{ \"check-attr\", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"cherry\", cmd_cherry, RUN_SETUP },\n+\t\t{ \"cherry-pick\", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"clean\", cmd_clean, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"commit\", cmd_commit, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"commit-tree\", cmd_commit_tree, RUN_SETUP },\n+\t\t{ \"config\", cmd_config },\n+\t\t{ \"count-objects\", cmd_count_objects, RUN_SETUP },\n+\t\t{ \"describe\", cmd_describe, RUN_SETUP },\n+\t\t{ \"diff\", cmd_diff },\n+\t\t{ \"diff-files\", cmd_diff_files },\n+\t\t{ \"diff-index\", cmd_diff_index, RUN_SETUP },\n+\t\t{ \"diff-tree\", cmd_diff_tree, RUN_SETUP },\n+\t\t{ \"fetch\", cmd_fetch, RUN_SETUP },\n+\t\t{ \"fetch-pack\", cmd_fetch_pack, RUN_SETUP },\n+\t\t{ \"fetch--tool\", cmd_fetch__tool, RUN_SETUP },\n+\t\t{ \"fmt-merge-msg\", cmd_fmt_merge_msg, RUN_SETUP },\n+\t\t{ \"for-each-ref\", cmd_for_each_ref, RUN_SETUP },\n+\t\t{ \"format-patch\", cmd_format_patch, RUN_SETUP },\n+\t\t{ \"fsck\", cmd_fsck, RUN_SETUP },\n+\t\t{ \"fsck-objects\", cmd_fsck, RUN_SETUP },\n+\t\t{ \"gc\", cmd_gc, RUN_SETUP },\n+\t\t{ \"get-tar-commit-id\", cmd_get_tar_commit_id },\n+\t\t{ \"grep\", cmd_grep, RUN_SETUP | USE_PAGER },\n+\t\t{ \"help\", cmd_help },\n+#ifndef NO_CURL\n+\t\t{ \"http-fetch\", cmd_http_fetch, RUN_SETUP },\n+#endif\n+\t\t{ \"init\", cmd_init_db },\n+\t\t{ \"init-db\", cmd_init_db },\n+\t\t{ \"log\", cmd_log, RUN_SETUP | USE_PAGER },\n+\t\t{ \"ls-files\", cmd_ls_files, RUN_SETUP },\n+\t\t{ \"ls-tree\", cmd_ls_tree, RUN_SETUP },\n+\t\t{ \"ls-remote\", cmd_ls_remote },\n+\t\t{ \"mailinfo\", cmd_mailinfo },\n+\t\t{ \"mailsplit\", cmd_mailsplit },\n+\t\t{ \"merge-base\", cmd_merge_base, RUN_SETUP },\n+\t\t{ \"merge-file\", cmd_merge_file },\n+\t\t{ \"merge-ours\", cmd_merge_ours, RUN_SETUP },\n+\t\t{ \"mv\", cmd_mv, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"name-rev\", cmd_name_rev, RUN_SETUP },\n+\t\t{ \"pack-objects\", cmd_pack_objects, RUN_SETUP },\n+\t\t{ \"peek-remote\", cmd_ls_remote },\n+\t\t{ \"pickaxe\", cmd_blame, RUN_SETUP },\n+\t\t{ \"prune\", cmd_prune, RUN_SETUP },\n+\t\t{ \"prune-packed\", cmd_prune_packed, RUN_SETUP },\n+\t\t{ \"push\", cmd_push, RUN_SETUP },\n+\t\t{ \"read-tree\", cmd_read_tree, RUN_SETUP },\n+\t\t{ \"reflog\", cmd_reflog, RUN_SETUP },\n+\t\t{ \"repo-config\", cmd_config },\n+\t\t{ \"rerere\", cmd_rerere, RUN_SETUP },\n+\t\t{ \"reset\", cmd_reset, RUN_SETUP },\n+\t\t{ \"rev-list\", cmd_rev_list, RUN_SETUP },\n+\t\t{ \"rev-parse\", cmd_rev_parse },\n+\t\t{ \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"rm\", cmd_rm, RUN_SETUP },\n+\t\t{ \"send-pack\", cmd_send_pack, RUN_SETUP },\n+\t\t{ \"shortlog\", cmd_shortlog, RUN_SETUP | USE_PAGER },\n+\t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n+\t\t{ \"show\", cmd_show, RUN_SETUP | USE_PAGER },\n+\t\t{ \"status\", cmd_status, RUN_SETUP | NEED_WORK_TREE },\n+\t\t{ \"stripspace\", cmd_stripspace },\n+\t\t{ \"symbolic-ref\", cmd_symbolic_ref, RUN_SETUP },\n+\t\t{ \"tag\", cmd_tag, RUN_SETUP },\n+\t\t{ \"tar-tree\", cmd_tar_tree },\n+\t\t{ \"unpack-objects\", cmd_unpack_objects, RUN_SETUP },\n+\t\t{ \"update-index\", cmd_update_index, RUN_SETUP },\n+\t\t{ \"update-ref\", cmd_update_ref, RUN_SETUP },\n+\t\t{ \"upload-archive\", cmd_upload_archive },\n+\t\t{ \"verify-tag\", cmd_verify_tag, RUN_SETUP },\n+\t\t{ \"version\", cmd_version },\n+\t\t{ \"whatchanged\", cmd_whatchanged, RUN_SETUP | USE_PAGER },\n+\t\t{ \"write-tree\", cmd_write_tree, RUN_SETUP },\n+\t\t{ \"verify-pack\", cmd_verify_pack },\n+\t\t{ \"show-ref\", cmd_show_ref, RUN_SETUP },\n+\t\t{ \"pack-refs\", cmd_pack_refs, RUN_SETUP },\n+\t};\n+\tint i;\n+\n+\t/* Turn \"git cmd --help\" into \"git help cmd\" */\n+\tif (argv[0] && argv[1] && !strcmp(argv[1], \"--help\")) {\n+\t\targv[1] = argv[0];\n+\t\targv[0] = cmd = \"help\";\n+\t}\n+\n+\tfor (i = 0; i < ARRAY_SIZE(commands); i++) {\n+\t\tint argc;\n+\t\tstruct cmd_struct *p = commands+i;\n+\t\tif (strcmp(p->cmd, cmd))\n+\t\t\tcontinue;\n+\t\trelease_all_objects();\n+\t\tdiscard_cache();\n+\t\tfor (argc = 0; argv[argc]; argc++)\n+\t\t\t; /* do nothing */\n+\t\texit(run_command(p, argc, argv));\n+\t}\n+\treturn -1;\n+}\n+\n int execv_git_cmd(const char **argv)\n {\n \tstruct strbuf cmd;\n \tconst char *tmp;\n \n+\t/* Try builtin first... */\n+\texecv_git_builtin(argv);\n+\n+\t/* ... and then external commands */\n \tstrbuf_init(&cmd, 0);\n \tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n \ndiff --git a/exec_cmd.h b/exec_cmd.h\nindex a892355..bb15425 100644\n--- a/exec_cmd.h\n+++ b/exec_cmd.h\n@@ -4,6 +4,7 @@\n extern void git_set_argv_exec_path(const char *exec_path);\n extern const char* git_exec_path(void);\n extern void setup_path(const char *);\n+extern int execv_git_builtin(const char **argv); /* NULL terminated */\n extern int execv_git_cmd(const char **argv); /* NULL terminated */\n extern int execl_git_cmd(const char *cmd, ...);\n \ndiff --git a/git.c b/git.c\nindex 95296aa..1523c4a 100644\n--- a/git.c\n+++ b/git.c\n@@ -3,9 +3,6 @@\n #include \"cache.h\"\n #include \"quote.h\"\n \n-const char git_usage_string[] =\n-\t\"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]\";\n-\n static int handle_options(const char*** argv, int* argc, int* envchanged)\n {\n \tint handled = 0;\n@@ -231,167 +228,6 @@ static int handle_alias(int *argcp, const char ***argv)\n \treturn ret;\n }\n \n-const char git_version_string[] = GIT_VERSION;\n-\n-#define RUN_SETUP\t(1<<0)\n-#define USE_PAGER\t(1<<1)\n-/*\n- * require working tree to be present -- anything uses this needs\n- * RUN_SETUP for reading from the configuration file.\n- */\n-#define NEED_WORK_TREE\t(1<<2)\n-\n-struct cmd_struct {\n-\tconst char *cmd;\n-\tint (*fn)(int, const char **, const char *);\n-\tint option;\n-};\n-\n-static int run_command(struct cmd_struct *p, int argc, const char **argv)\n-{\n-\tint status;\n-\tstruct stat st;\n-\tconst char *prefix;\n-\n-\tprefix = NULL;\n-\tif (p->option & RUN_SETUP)\n-\t\tprefix = setup_git_directory();\n-\tif (p->option & USE_PAGER)\n-\t\tsetup_pager();\n-\tif (p->option & NEED_WORK_TREE)\n-\t\tsetup_work_tree();\n-\n-\ttrace_argv_printf(argv, argc, \"trace: built-in: git\");\n-\n-\tstatus = p->fn(argc, argv, prefix);\n-\tif (status)\n-\t\treturn status & 0xff;\n-\n-\t/* Somebody closed stdout? */\n-\tif (fstat(fileno(stdout), &st))\n-\t\treturn 0;\n-\t/* Ignore write errors for pipes and sockets.. */\n-\tif (S_ISFIFO(st.st_mode) || S_ISSOCK(st.st_mode))\n-\t\treturn 0;\n-\n-\t/* Check for ENOSPC and EIO errors.. */\n-\tif (fflush(stdout))\n-\t\tdie(\"write failure on standard output: %s\", strerror(errno));\n-\tif (ferror(stdout))\n-\t\tdie(\"unknown write failure on standard output\");\n-\tif (fclose(stdout))\n-\t\tdie(\"close failed on standard output: %s\", strerror(errno));\n-\treturn 0;\n-}\n-\n-static void handle_internal_command(int argc, const char **argv)\n-{\n-\tconst char *cmd = argv[0];\n-\tstatic struct cmd_struct commands[] = {\n-\t\t{ \"add\", cmd_add, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"annotate\", cmd_annotate, RUN_SETUP },\n-\t\t{ \"apply\", cmd_apply },\n-\t\t{ \"archive\", cmd_archive },\n-\t\t{ \"blame\", cmd_blame, RUN_SETUP },\n-\t\t{ \"branch\", cmd_branch, RUN_SETUP },\n-\t\t{ \"bundle\", cmd_bundle },\n-\t\t{ \"cat-file\", cmd_cat_file, RUN_SETUP },\n-\t\t{ \"checkout-index\", cmd_checkout_index,\n-\t\t\tRUN_SETUP | NEED_WORK_TREE},\n-\t\t{ \"check-ref-format\", cmd_check_ref_format },\n-\t\t{ \"check-attr\", cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"cherry\", cmd_cherry, RUN_SETUP },\n-\t\t{ \"cherry-pick\", cmd_cherry_pick, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"clean\", cmd_clean, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"commit\", cmd_commit, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"commit-tree\", cmd_commit_tree, RUN_SETUP },\n-\t\t{ \"config\", cmd_config },\n-\t\t{ \"count-objects\", cmd_count_objects, RUN_SETUP },\n-\t\t{ \"describe\", cmd_describe, RUN_SETUP },\n-\t\t{ \"diff\", cmd_diff },\n-\t\t{ \"diff-files\", cmd_diff_files },\n-\t\t{ \"diff-index\", cmd_diff_index, RUN_SETUP },\n-\t\t{ \"diff-tree\", cmd_diff_tree, RUN_SETUP },\n-\t\t{ \"fetch\", cmd_fetch, RUN_SETUP },\n-\t\t{ \"fetch-pack\", cmd_fetch_pack, RUN_SETUP },\n-\t\t{ \"fetch--tool\", cmd_fetch__tool, RUN_SETUP },\n-\t\t{ \"fmt-merge-msg\", cmd_fmt_merge_msg, RUN_SETUP },\n-\t\t{ \"for-each-ref\", cmd_for_each_ref, RUN_SETUP },\n-\t\t{ \"format-patch\", cmd_format_patch, RUN_SETUP },\n-\t\t{ \"fsck\", cmd_fsck, RUN_SETUP },\n-\t\t{ \"fsck-objects\", cmd_fsck, RUN_SETUP },\n-\t\t{ \"gc\", cmd_gc, RUN_SETUP },\n-\t\t{ \"get-tar-commit-id\", cmd_get_tar_commit_id },\n-\t\t{ \"grep\", cmd_grep, RUN_SETUP | USE_PAGER },\n-\t\t{ \"help\", cmd_help },\n-#ifndef NO_CURL\n-\t\t{ \"http-fetch\", cmd_http_fetch, RUN_SETUP },\n-#endif\n-\t\t{ \"init\", cmd_init_db },\n-\t\t{ \"init-db\", cmd_init_db },\n-\t\t{ \"log\", cmd_log, RUN_SETUP | USE_PAGER },\n-\t\t{ \"ls-files\", cmd_ls_files, RUN_SETUP },\n-\t\t{ \"ls-tree\", cmd_ls_tree, RUN_SETUP },\n-\t\t{ \"ls-remote\", cmd_ls_remote },\n-\t\t{ \"mailinfo\", cmd_mailinfo },\n-\t\t{ \"mailsplit\", cmd_mailsplit },\n-\t\t{ \"merge-base\", cmd_merge_base, RUN_SETUP },\n-\t\t{ \"merge-file\", cmd_merge_file },\n-\t\t{ \"merge-ours\", cmd_merge_ours, RUN_SETUP },\n-\t\t{ \"mv\", cmd_mv, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"name-rev\", cmd_name_rev, RUN_SETUP },\n-\t\t{ \"pack-objects\", cmd_pack_objects, RUN_SETUP },\n-\t\t{ \"peek-remote\", cmd_ls_remote },\n-\t\t{ \"pickaxe\", cmd_blame, RUN_SETUP },\n-\t\t{ \"prune\", cmd_prune, RUN_SETUP },\n-\t\t{ \"prune-packed\", cmd_prune_packed, RUN_SETUP },\n-\t\t{ \"push\", cmd_push, RUN_SETUP },\n-\t\t{ \"read-tree\", cmd_read_tree, RUN_SETUP },\n-\t\t{ \"reflog\", cmd_reflog, RUN_SETUP },\n-\t\t{ \"repo-config\", cmd_config },\n-\t\t{ \"rerere\", cmd_rerere, RUN_SETUP },\n-\t\t{ \"reset\", cmd_reset, RUN_SETUP },\n-\t\t{ \"rev-list\", cmd_rev_list, RUN_SETUP },\n-\t\t{ \"rev-parse\", cmd_rev_parse },\n-\t\t{ \"revert\", cmd_revert, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"rm\", cmd_rm, RUN_SETUP },\n-\t\t{ \"send-pack\", cmd_send_pack, RUN_SETUP },\n-\t\t{ \"shortlog\", cmd_shortlog, RUN_SETUP | USE_PAGER },\n-\t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n-\t\t{ \"show\", cmd_show, RUN_SETUP | USE_PAGER },\n-\t\t{ \"status\", cmd_status, RUN_SETUP | NEED_WORK_TREE },\n-\t\t{ \"stripspace\", cmd_stripspace },\n-\t\t{ \"symbolic-ref\", cmd_symbolic_ref, RUN_SETUP },\n-\t\t{ \"tag\", cmd_tag, RUN_SETUP },\n-\t\t{ \"tar-tree\", cmd_tar_tree },\n-\t\t{ \"unpack-objects\", cmd_unpack_objects, RUN_SETUP },\n-\t\t{ \"update-index\", cmd_update_index, RUN_SETUP },\n-\t\t{ \"update-ref\", cmd_update_ref, RUN_SETUP },\n-\t\t{ \"upload-archive\", cmd_upload_archive },\n-\t\t{ \"verify-tag\", cmd_verify_tag, RUN_SETUP },\n-\t\t{ \"version\", cmd_version },\n-\t\t{ \"whatchanged\", cmd_whatchanged, RUN_SETUP | USE_PAGER },\n-\t\t{ \"write-tree\", cmd_write_tree, RUN_SETUP },\n-\t\t{ \"verify-pack\", cmd_verify_pack },\n-\t\t{ \"show-ref\", cmd_show_ref, RUN_SETUP },\n-\t\t{ \"pack-refs\", cmd_pack_refs, RUN_SETUP },\n-\t};\n-\tint i;\n-\n-\t/* Turn \"git cmd --help\" into \"git help cmd\" */\n-\tif (argc > 1 && !strcmp(argv[1], \"--help\")) {\n-\t\targv[1] = argv[0];\n-\t\targv[0] = cmd = \"help\";\n-\t}\n-\n-\tfor (i = 0; i < ARRAY_SIZE(commands); i++) {\n-\t\tstruct cmd_struct *p = commands+i;\n-\t\tif (strcmp(p->cmd, cmd))\n-\t\t\tcontinue;\n-\t\texit(run_command(p, argc, argv));\n-\t}\n-}\n-\n int main(int argc, const char **argv)\n {\n \tconst char *cmd = argv[0] ? argv[0] : \"git-help\";\n@@ -423,7 +259,7 @@ int main(int argc, const char **argv)\n \tif (!prefixcmp(cmd, \"git-\")) {\n \t\tcmd += 4;\n \t\targv[0] = cmd;\n-\t\thandle_internal_command(argc, argv);\n+\t\texecv_git_builtin(argv);\n \t\tdie(\"cannot handle %s internally\", cmd);\n \t}\n \n@@ -451,10 +287,6 @@ int main(int argc, const char **argv)\n \tsetup_path(cmd_path);\n \n \twhile (1) {\n-\t\t/* See if it's an internal command */\n-\t\thandle_internal_command(argc, argv);\n-\n-\t\t/* .. then try the external ones */\n \t\texecv_git_cmd(argv);\n \n \t\t/* It could be an alias -- this works around the insanity\n-- \n1.5.3.6.2112.ge2263\n"},{"id":"61620","messageId":"7v3aul1xmt.fsf@gitster.siamese.dyndns.org","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712020146240.27959@racer.site","subject":"Re: [PATCH 0/3] Call builtin functions directly, was Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-12-02T05:19:54Z","receivedAt":"2007-12-02T05:19:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Okay, I bit the apple and tried to move the builtins into the library, and \n> rename handle_internal_command into execv_git_builtin(), moving it into \n> exec-cmd.c.\n>\n> Big mistake.\n\nI really feel this should not go in. Anything called exec _should_\nassure the callers that the new command will start from a clean slate,\nand the way to give that assurance is by actually doing exec(), not\nintroducing \"clean-up\" functions for random things we can think of (like\ncached objects) and risking of forgetting some others. I do not think\nthe complexity is worth it.\n\nThe first step we have decided to take is to move git-foo form out of\nusers' PATH. This would reduce the cluttered PATH problem, and it means\nnot all of external commands have to become built-ins on a single flag\nday. I also think it has always been a nice touch that we allowed users\nto drop their own custom git-foo script to their path and call \"git foo\"\nas if it is part of the official git suite, so spawning commands in\ngit-foo form needs to be supported via GIT_EXEC_PATH even if everything\neventually becomes built-in.\n\nSo I would prefer doing something like this instead for v1.5.5 (see\nthe top of updated release notes for 1.5.4 for deprecation notice).\n\n * execv_git_cmd() function will exec \"git\" with the given subcommand\n and its arguments;\n\n * The command dispatcher of git potty itself will first try the\n built-ins, and then try externals in dash form (which cannot be done\n with execv_git_cmd() anymore), and then aliases.\n\n * Just to be nice, we allow git-shell to treat \"git foo arg\" as if\n \"git-foo arg\" was given, but it continues to use execv_git_cmd(), and\n starts from a clean slate.\n\n---\n exec_cmd.c | 31 ++++++++++++-------------------\n git.c | 32 +++++++++++++++++++++++++++++++-\n shell.c | 26 +++++++++++++++-----------\n 3 files changed, 58 insertions(+), 31 deletions(-)\n\ndiff --git a/exec_cmd.c b/exec_cmd.c\nindex 2d0a758..10b2908 100644\n--- a/exec_cmd.c\n+++ b/exec_cmd.c\n@@ -65,32 +65,25 @@ void setup_path(const char *cmd_path)\n \n int execv_git_cmd(const char **argv)\n {\n-\tstruct strbuf cmd;\n-\tconst char *tmp;\n-\n-\tstrbuf_init(&cmd, 0);\n-\tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n+\tint argc;\n+\tconst char **nargv;\n \n-\t/*\n-\t * argv[0] must be the git command, but the argv array\n-\t * belongs to the caller, and may be reused in\n-\t * subsequent loop iterations. Save argv[0] and\n-\t * restore it on error.\n-\t */\n-\ttmp = argv[0];\n-\targv[0] = cmd.buf;\n+\tfor (argc = 0; argv[argc]; argc++)\n+\t\t; /* just counting */\n+\tnargv = xmalloc(sizeof(*nargv) * (argc + 2));\n \n-\ttrace_argv_printf(argv, -1, \"trace: exec:\");\n+\tnargv[0] = \"git\";\n+\tfor (argc = 0; argv[argc]; argc++)\n+\t\tnargv[argc + 1] = argv[argc];\n+\tnargv[argc + 1] = NULL;\n+\ttrace_argv_printf(nargv, -1, \"trace: exec:\");\n \n \t/* execvp() can only ever return if it fails */\n-\texecvp(cmd.buf, (char **)argv);\n+\texecvp(\"git\", (char **)nargv);\n \n \ttrace_printf(\"trace: exec failed: %s\\n\", strerror(errno));\n \n-\targv[0] = tmp;\n-\n-\tstrbuf_release(&cmd);\n-\n+\tfree(nargv);\n \treturn -1;\n }\n \ndiff --git a/git.c b/git.c\nindex 01bbbc7..d690426 100644\n--- a/git.c\n+++ b/git.c\n@@ -382,6 +382,36 @@ static void handle_internal_command(int argc, const char **argv)\n \t}\n }\n \n+static void execv_dashed_external(const char **argv)\n+{\n+\tstruct strbuf cmd;\n+\tconst char *tmp;\n+\n+\tstrbuf_init(&cmd, 0);\n+\tstrbuf_addf(&cmd, \"git-%s\", argv[0]);\n+\n+\t/*\n+\t * argv[0] must be the git command, but the argv array\n+\t * belongs to the caller, and may be reused in\n+\t * subsequent loop iterations. Save argv[0] and\n+\t * restore it on error.\n+\t */\n+\ttmp = argv[0];\n+\targv[0] = cmd.buf;\n+\n+\ttrace_argv_printf(argv, -1, \"trace: exec:\");\n+\n+\t/* execvp() can only ever return if it fails */\n+\texecvp(cmd.buf, (char **)argv);\n+\n+\ttrace_printf(\"trace: exec failed: %s\\n\", strerror(errno));\n+\n+\targv[0] = tmp;\n+\n+\tstrbuf_release(&cmd);\n+}\n+\n+\n int main(int argc, const char **argv)\n {\n \tconst char *cmd = argv[0] ? argv[0] : \"git-help\";\n@@ -445,7 +475,7 @@ int main(int argc, const char **argv)\n \t\thandle_internal_command(argc, argv);\n \n \t\t/* .. then try the external ones */\n-\t\texecv_git_cmd(argv);\n+\t\texecv_dashed_external(argv);\n \n \t\t/* It could be an alias -- this works around the insanity\n \t\t * of overriding \"git log\" with \"git show\" by having\ndiff --git a/shell.c b/shell.c\nindex 9826109..729797c 100644\n--- a/shell.c\n+++ b/shell.c\n@@ -19,17 +19,13 @@ static int do_generic_cmd(const char *me, char *arg)\n \treturn execv_git_cmd(my_argv);\n }\n \n-static int do_cvs_cmd(const char *me, char *arg)\n+static int do_cvs_cmd(void)\n {\n \tconst char *cvsserver_argv[3] = {\n \t\t\"cvsserver\", \"server\", NULL\n \t};\n \n-\tif (!arg || strcmp(arg, \"server\"))\n-\t\tdie(\"git-cvsserver only handles server: %s\", arg);\n-\n \tsetup_path(NULL);\n-\n \treturn execv_git_cmd(cvsserver_argv);\n }\n \n@@ -40,7 +36,6 @@ static struct commands {\n } cmd_list[] = {\n \t{ \"git-receive-pack\", do_generic_cmd },\n \t{ \"git-upload-pack\", do_generic_cmd },\n-\t{ \"cvs\", do_cvs_cmd },\n \t{ NULL },\n };\n \n@@ -49,15 +44,24 @@ int main(int argc, char **argv)\n \tchar *prog;\n \tstruct commands *cmd;\n \n+\t/*\n+\t * Special hack to pretend to be a CVS server\n+\t */\n \tif (argc == 2 && !strcmp(argv[1], \"cvs server\"))\n-\t\targv--;\n-\t/* We want to see \"-c cmd args\", and nothing else */\n-\telse if (argc != 3 || strcmp(argv[1], \"-c\"))\n+\t\texit(do_cvs_cmd());\n+\n+\t/*\n+\t * We do not accept anything but \"-c\" followed by \"cmd arg\",\n+\t * where \"cmd\" is a very limited subset of git commands.\n+\t */\n+\tif (argc != 3 || strcmp(argv[1], \"-c\"))\n \t\tdie(\"What do you think I am? A shell?\");\n \n \tprog = argv[2];\n-\targv += 2;\n-\targc -= 2;\n+\tif (!strncmp(prog, \"git\", 3) && isspace(prog[3]))\n+\t\t/* Accept \"git foo\" as if the caller said \"git-foo\". */\n+\t\tprog[3] = '-';\n+\n \tfor (cmd = cmd_list ; cmd->name ; cmd++) {\n \t\tint len = strlen(cmd->name);\n \t\tchar *arg;\n"},{"id":"61622","messageId":"fcaeb9bf0712012150p5430b1fel1addf675adf0aaf0@mail.gmail.com","threadId":"11033","inReplyTo":"7vve7i43ec.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2007-12-02T05:50:05Z","receivedAt":"2007-12-02T05:50:05Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Dec 2, 2007 2:32 AM, Junio C Hamano wrote:\n> \"Nguyen Thai Ngoc Duy\" writes:\n>\n> > On Nov 30, 2007 10:50 PM, Linus Torvalds wrote:\n> >\n> >> Well, different people will want different viewers *anyway* (ie some will\n> >> prefer qgit etc), so how about making \"git view\" be something that\n> >> literally acts as a built-in alias that just defaults to running gitk (if\n> >> for no other reason than the fact that gitk is the one that ships with\n> >> git, and simply has most users).\n> >\n> > We already have \"git show\", now we gonna get \"git view\", git trainers\n> > may have hard time explaining this one shows you a particular object\n> > while the other one shows you history. How about \"git lshistory\" (from\n> > clearcase land) or git show --history?\n>\n> Heh, we have \"bisect visualize\". How about \"git visualize\"?\n>\n\n\"git visualize\"++\n\n\n-- \nDuy\n"},{"id":"61634","messageId":"Pine.LNX.4.64.0712021133480.27959@racer.site","threadId":"11033","inReplyTo":"7v3aul1xmt.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 0/3] Call builtin functions directly, was Re: [PATCH] transport.c: call dash-less form of receive-pack and upload-pack on remote","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T11:35:48Z","receivedAt":"2007-12-02T11:35:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 1 Dec 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Okay, I bit the apple and tried to move the builtins into the library, \n> > and rename handle_internal_command into execv_git_builtin(), moving it \n> > into exec-cmd.c.\n> >\n> > Big mistake.\n> \n> I really feel this should not go in.\n\nHmm.\n\nMy rationale was not only avoiding an exec() (which I would find worth it \non its own), but because this would be a non-verbal step towards \nlibification.\n\nCiao,\nDscho\n"},{"id":"61645","messageId":"FFEBE8BB-E764-4DD0-A7DC-8CC01659D9BC@wincent.com","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0711302306580.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-12-02T15:02:07Z","receivedAt":"2007-12-02T15:02:07Z","isPatch":true,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 1/12/2007, a las 0:10, Johannes Schindelin escribió:\n\n> To me, it is mighty annoying anybody brings up that \"144 commands\"\n> argument Linus was referring to, and if there is _any_ way to shut up\n> those bikeshedders, I am all for it.\n\nThis is not a bikeshed argument and it is not an \"idiotic \ncomplaint\" (to use Linus' phrase). It is a legitimate concern and a \n*real* UI problem.\n\nYou and Linus don't care that there are 140+ Git commands and I \nimagine that you know exactly what each of them does.\n\nI don't really care either because although I don't know what every \nsingle command does, I know what the 20 or 30 commands I personally \nneed for my own workflow do.\n\nThe problem is for *newcomers* to Git who sit down for the first time \nand ask themselves, \"Now, how do I...?\". This is not an idiotic \ncomplaint but a legitimate concern about a real UI problem.\n\nHonestly, Johannes, do you think the following is a good UI?\n\n$ git\nDisplay all 148 possibilities? (y or n)\ngit* git-cvsimport* git-local- \nfetch* git-peek-remote* git-show-index*\ngit-add* git-cvsserver* git- \nlog* git-prune* git-show-ref*\ngit-add--interactive* git-daemon* git-lost- \nfound* git-prune-packed* git-ssh-fetch*\ngit-am* git-describe* git-ls- \nfiles* git-pull* git-ssh-pull*\ngit-annotate* git-diff* git-ls- \nremote* git-push* git-ssh-push*\ngit-apply* git-diff-files* git-ls- \ntree* git-quiltimport* git-ssh-upload*\ngit-applymbox git-diff-index* git- \nmailinfo* git-read-tree* git-stash*\ngit-applypatch git-diff-tree* git- \nmailsplit* git-rebase* git-status*\ngit-archimport* git-fast-import* git- \nmerge* git-rebase--interactive* git-stripspace*\ngit-archive* git-fetch* git-merge- \nbase* git-receive-pack* git-submodule*\ngit-bisect* git-fetch--tool* git-merge- \nfile* git-reflog* git-svn*\ngit-blame* git-fetch-pack* git-merge- \nindex* git-relink* git-svnimport\ngit-branch* git-filter-branch* git-merge- \noctopus* git-remote* git-symbolic-ref*\ngit-bundle* git-fmt-merge-msg* git-merge-one- \nfile* git-repack* git-tag*\ngit-cat-file* git-for-each-ref* git-merge- \nours* git-repo-config* git-tar-tree*\ngit-check-attr* git-format-patch* git-merge- \nrecursive* git-request-pull* git-unpack-file*\ngit-check-ref-format* git-fsck* git-merge- \nresolve* git-rerere* git-unpack-objects*\ngit-checkout* git-fsck-objects* git-merge- \nstupid* git-reset* git-update-index*\ngit-checkout-index* git-gc* git-merge- \nsubtree* git-rev-list* git-update-ref*\ngit-cherry* git-get-tar-commit-id* git-merge- \ntree* git-rev-parse* git-update-server-info*\ngit-cherry-pick* git-grep* git- \nmergetool* git-revert* git-upload-archive*\ngit-citool git-gui/ git- \nmktag* git-rm* git-upload-pack*\ngit-clean* git-hash-object* git- \nmktree* git-runstatus* git-var*\ngit-clone* git-http-fetch* git- \nmv* git-send-email* git-verify-pack*\ngit-commit* git-http-push* git-name- \nrev* git-send-pack* git-verify-tag*\ngit-commit-tree* git-imap-send* git-pack- \nobjects* git-sh-setup* git-whatchanged*\ngit-config* git-index-pack* git-pack- \nredundant* git-shell* git-write-tree*\ngit-convert-objects git-init* git-pack- \nrefs* git-shortlog* gitk\ngit-count-objects* git-init-db* git-parse- \nremote* git-show*\ngit-cvsexportcommit* git-instaweb* git-patch- \nid* git-show-branch*\n\nWould you argue that this screenshot shows a sane UI?\n\n\n\nNote: I am not complaining about the *number* of commands; I myself \nfind them highly useful for scripting. I am saying that the \n*visibility* of those commands is the problem. That's why I support \nthe efforts to move most of this stuff out of the default PATH. We're \nnot talking about getting rid of it, just about putting it somewhere \nmore appropriate in order to correct what is basically a *hideous* \nuser interface for the beginner.\n\nCheers,\nWincent\n"},{"id":"61654","messageId":"Pine.LNX.4.64.0712021637250.27959@racer.site","threadId":"11033","inReplyTo":"FFEBE8BB-E764-4DD0-A7DC-8CC01659D9BC@wincent.com","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T16:39:28Z","receivedAt":"2007-12-02T16:39:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Dec 2007, Wincent Colaiuta wrote:\n\n> El 1/12/2007, a las 0:10, Johannes Schindelin escribi?:\n> \n> > To me, it is mighty annoying anybody brings up that \"144 commands\" \n> > argument Linus was referring to, and if there is _any_ way to shut up \n> > those bikeshedders, I am all for it.\n> \n> This is not a bikeshed argument and it is not an \"idiotic complaint\" (to \n> use Linus' phrase). It is a legitimate concern and a *real* UI problem.\n> \n> You and Linus don't care that there are 140+ Git commands and I imagine \n> that you know exactly what each of them does.\n\nOkay, how many executables are there in your /usr/bin/? Here there are \n2973.\n\nGuess what. I am not intimidated by that number.\n\nCiao,\nDscho\n"},{"id":"61656","messageId":"4752E3D0.6030802@obry.net","threadId":"11033","inReplyTo":"Pine.LNX.4.64.0712021637250.27959@racer.site","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2007-12-02T16:56:48Z","receivedAt":"2007-12-02T16:56:48Z","isPatch":true,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Johannes Schindelin a écrit :\n> Okay, how many executables are there in your /usr/bin/? Here there are \n> 2973.\n> Guess what. I am not intimidated by that number.\n\nGood, and look in /usr/bin, all those 2973 binary are all disconnected.\n\nHere we are speaking about a tool as a whole : Git.\n\nAnd I agree that hiding some of them will probably help new comers. We\ncan also argue that a new comers should read some documentation :)\n\nAfter all I'm not sure what's the right move !\n\nAt least let me say something constructive :) I'm a new comer to Git.\nI've read many documentations before grabbing the system and I've not\nbeen impressed by the number of binaries in /usr/bin... Because I've\nalmost never looked there. Most of the time I'm using \"git \" and\nthe bash completion feature is just right for me.\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"61663","messageId":"Pine.LNX.4.64.0712021718460.27959@racer.site","threadId":"11033","inReplyTo":"4752E3D0.6030802@obry.net","subject":"Re: [PATCH] Move all dashed form git commands to libexecdir","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-02T17:23:52Z","receivedAt":"2007-12-02T17:23:52Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 2 Dec 2007, Pascal Obry wrote:\n\n> Johannes Schindelin a ?crit :\n> > Okay, how many executables are there in your /usr/bin/? Here there \n> > are 2973. Guess what. I am not intimidated by that number.\n> \n> Good, and look in /usr/bin, all those 2973 binary are all disconnected.\n> \n> Here we are speaking about a tool as a whole : Git.\n\nNo, we are speaking about different commands, such as commit, fetch, push, \netc.\n\nI refuse to believe that you cannot see the equivalence.\n\n> I've read many documentations before grabbing the system and I've not\n> been impressed by the number of binaries in /usr/bin... Because I've\n> almost never looked there.\n\nExactly my point.\n\n> Most of the time I'm using \"git \" and the bash completion feature \n> is just right for me.\n\nBash completion is really something fine.\n\nBut even without, I do not see a problem: many cvs users used only three \nout of 32 commands (most CVS users I personally know/knew only called add, \ncommit and update). You could even see all 32 commands when calling the \nclunky command line \"cvs --help-commands\". I am convinced we're already \nmore user-friendly than that.\n\nCiao,\nDscho\n"}]}