{"thread":{"id":"15184","subject":"[RFD] On deprecating \"git-foo\" for builtins","startedAt":"2008-08-24T03:33:10Z","lastAt":"2008-09-04T04:57:47Z","messageCount":193,"participants":["Junio C Hamano","Linus Torvalds","Imran M Yousuf","Stefan Richter","David Woodhouse","Geert Uytterhoeven","Andi Kleen","Ben Collins","Felipe Contreras","Johannes Schindelin","A Large Angry SCM","Jean Delvare","Shawn O. Pearce","Jeff King","Kristian Høgsberg","Matthias Kestenholz","Petr Baudis","Takashi Iwai","Bruce Stephens","Jakub Narebski","Teemu Likonen","Nguyen Thai Ngoc Duy","Dominik Brodowski","Al Viro","Daniel Barkalow","H. Peter Anvin","Steven Rostedt","Willy Tarreau","Matthieu Moy","Perry Wagle","Nicolas Pitre","Matthew Wilcox","Jay Soffian","Ulrich Windl","Andreas Ericsson","Karl Hasselström","Krzysztof Halasa","Jeff Garzik","Adrian Bunk","Russell King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"88343","messageId":"7vprnzt7d5.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":null,"subject":"[RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-24T03:33:10Z","receivedAt":"2008-08-24T03:33:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"People seems to have quite strong negative feelings on the removal of\ndashed form \"git-foo\" commands from their $PATH.\n\nWe have deprecated the dashed form in early 2006, and announced that 1.6.0\nwill remove them from $PATH in the 1.5.4 release notes, with instructions\non how to update their scripts before 1.6.0 happens. Many people knew\nabout this transition, but they didn't do anything about it. Since 2005,\ngit has matured enough that majority of people are using it without\nbuilding one themselves, without a chance to even read Release Notes.\n\nThe pain was exacerbated partly because we tried to be too nice during the\n\"deprecation\" period, not to annoy people and not to break people's\nscripts.\n\nBut that niceness backfired. Many people seem to argue now that we should\nhave annoyed people by throwing loud deprecation notices to stderr when\nthey typed \"git-foo\", and we should have risked breaking their scripts iff\nthey relied on not seeing anything extra on the stderr.\n\nI am 50% sympathetic to them, while the remainder of me think that they\ncan say that in retrospect only because they didn't actually got annoyed\nwith such extra messages and they did not have to fix their scripts before\nthe actual switch-over happened. If we did go the \"annoy them early\"\nroute, I am sure they would have complained as loudly.\n\nThat's all history now anyway. We should try to do better the next time,\nwhich is much more important, and that is the topic of this message.\n\nNow, we haven't set the timeframe yet, but the original plan, advocated by\nLinus and others, was to eventually stop installing \"git-foo\" form on the\nfilesystem for builtin commands. If we were to do this, we should plan\nhow the deprecation period for this change should look like. I think the\nsequence of events would look like this:\n\n (1) Declare that the dashed form are deprecated even in scripts that use\n \"git --exec-path\" the way 1.5.4 release notes suggested (it does not\n make sense to say \"deprecated only for builtins\", as the distinction\n between builtins and others are implementation details) and will be\n removed in 1.7.0;\n\n (2) Update git.c (the \"git\" wrapper) so that when the command is invoked\n in \"git-foo\" form for a builtin, issue messages to the standard error\n stream about the deprecation. Also, when the wrapper invokes an\n external \"git-foo\" command, it exports an environment variable (say,\n \"GIT_WRAPPER_IS_RUNNING_YOU\");\n\n Update non-builtin commands and scripts to first check the\n environment variable, and otherwise issue the same deprecation\n message, and then unset the environment variable before continuing.\n\n (3) At 1.7.0, stop installing the hardlinks to builtin commands.\n\nThere is one alternative, and one augmentation:\n\n (A) We do not do anything.\n\n (B) In addition to the main transition plan, outside git, prepare an\n optional \"git-old-style\" package that installs many \"git-foo\"\n wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n People who like the dashed form can keep typing \"git-foo\", even\n though that will cost them two exec()s.\n\nI personally do not mind seeing dozens of git-foo commands in /usr/bin,\ndid not have strong opinion on the transition we just did either way, but:\n\n * Alternative (A) does not logically make much sense. Now with 1.6.0,\n people are strongly encouraged to use \"git foo\" form already.\n\n * Variant (B) feels quite backwards and I think it will have a negative\n effect on our userbase in the longer term. People who train their\n fingers to say \"git-foo\" on machines with the \"git-old-style\" package\n will have hard time adjusting to working on machines without it.\n"},{"id":"88347","messageId":"alpine.LFD.1.10.0808232120420.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"7vprnzt7d5.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-24T04:23:42Z","receivedAt":"2008-08-24T04:23:42Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 23 Aug 2008, Junio C Hamano wrote:\n> \n> There is one alternative, and one augmentation:\n> \n> (A) We do not do anything.\n> \n> (B) In addition to the main transition plan, outside git, prepare an\n> optional \"git-old-style\" package that installs many \"git-foo\"\n> wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n> People who like the dashed form can keep typing \"git-foo\", even\n> though that will cost them two exec()s.\n\nI actually suspect that (A) is fine.\n\nI suggested removing the \"git-xyzzy\" hardlinks entirely, but that was just \nbecause I didn't think anybody wanted them.\n\nBut given that with the 1.6.0 model you can always just do\n\n\tPATH=\"PATH:$(git --exec-path)\"\n\nin your .bashrc or similar to get the git-xyzzy form, and given that \nclearly some people like using them, there's really no downside to keeping \nthem.\n\nI _would_ suggest against putting them in /usr/bin, even as a \n\"compatibility plan\". Just expose them to people who want them, who can \nreally quite easily do the above PATH setting.\n\n\t\tLinus\n"},{"id":"88349","messageId":"7bfdc29a0808232154l3619fe0s3112620e4028e769@mail.gmail.com","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808232120420.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Imran M Yousuf","fromEmail":"imyousuf@gmail.com","sentAt":"2008-08-24T04:54:05Z","receivedAt":"2008-08-24T04:54:05Z","isPatch":false,"sender":{"key":"imyousuf@gmail.com","avatar":"https://gravatar.com/avatar/fda3c870262849d03c7b9c4d288842e128d6d80769fa7bc2d22731b7597928be?d=mp&s=160"},"body":"On Sun, Aug 24, 2008 at 10:23 AM, Linus Torvalds\n wrote:\n>\n>\n> On Sat, 23 Aug 2008, Junio C Hamano wrote:\n>>\n>> There is one alternative, and one augmentation:\n>>\n>> (A) We do not do anything.\n>>\n>> (B) In addition to the main transition plan, outside git, prepare an\n>> optional \"git-old-style\" package that installs many \"git-foo\"\n>> wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n>> People who like the dashed form can keep typing \"git-foo\", even\n>> though that will cost them two exec()s.\n>\n> I actually suspect that (A) is fine.\n>\n> I suggested removing the \"git-xyzzy\" hardlinks entirely, but that was just\n> because I didn't think anybody wanted them.\n>\n> But given that with the 1.6.0 model you can always just do\n>\n> PATH=\"PATH:$(git --exec-path)\"\n>\n\nIf it is simple enough to get the git-abc commands by simply editing\nthe PATH var then I would have to agree that (A) is the option I would\nprefer as well (not that I am as important as Linus though :)). I am\nalso using the git-abc formats in some of my scripts but I would\nrather edit the PATH variable than to have then installed in /usr/bin\n(Not to mention that I will be update to 'git abc' as soon as I have\ntime :)).\n\n> in your .bashrc or similar to get the git-xyzzy form, and given that\n> clearly some people like using them, there's really no downside to keeping\n> them.\n>\n> I _would_ suggest against putting them in /usr/bin, even as a\n> \"compatibility plan\". Just expose them to people who want them, who can\n> really quite easily do the above PATH setting.\n>\n> Linus\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n\nBest regards\n\n-- \nImran M Yousuf\nEmail: imran@smartitengineering.com\nBlog: http://imyousuf-tech.blogs.smartitengineering.com/\nMobile: +880-1711402557\n"},{"id":"88354","messageId":"48B11E60.1020506@s5r6.in-berlin.de","threadId":"15184","inReplyTo":"7vprnzt7d5.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2008-08-24T08:40:00Z","receivedAt":"2008-08-24T08:40:00Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Junio C Hamano wrote:\n> People seems to have quite strong negative feelings on the removal of\n> dashed form \"git-foo\" commands from their $PATH.\n\nSome of them may appreciate git-completion.bash. On my box I found it \nnamed /usr/share/bash-completion/git.\n-- \nStefan Richter\n-=====-==--- =--- ==---\nhttp://arcgraph.de/sr/\n"},{"id":"88444","messageId":"1219664940.9583.42.camel@pmac.infradead.org","threadId":"15184","inReplyTo":"7vprnzt7d5.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-08-25T11:49:00Z","receivedAt":"2008-08-25T11:49:00Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:\n> \n> There is one alternative, and one augmentation:\n> \n> (A) We do not do anything.\n> \n> (B) In addition to the main transition plan, outside git, prepare an\n> optional \"git-old-style\" package that installs many \"git-foo\"\n> wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n> People who like the dashed form can keep typing \"git-foo\", even\n> though that will cost them two exec()s.\n\n (C) Just don't do it. Leave the git-foo commands as they were. They\n weren't actually hurting anyone, and you don't actually _gain_\n anything by removing them. For those occasional nutters who\n _really_ care about the size of /usr/bin, give them the _option_\n of a 'make install' without installing the aliases.\n\n(Oh look, my /usr/bin has 3806 files in it. And except when I\naccidentally point the $%#@&! GNOME file dialog box at it, I don't\n_care_.)\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"88447","messageId":"Pine.LNX.4.64.0808251415010.3893@vixen.sonytel.be","threadId":"15184","inReplyTo":"1219664940.9583.42.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Geert Uytterhoeven","fromEmail":"geert.uytterhoeven@sonycom.com","sentAt":"2008-08-25T12:17:44Z","receivedAt":"2008-08-25T12:17:44Z","isPatch":false,"sender":{"key":"geert.uytterhoeven@sonycom.com","avatar":null},"body":"On Mon, 25 Aug 2008, David Woodhouse wrote:\n> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:\n> > There is one alternative, and one augmentation:\n> > \n> > (A) We do not do anything.\n> > \n> > (B) In addition to the main transition plan, outside git, prepare an\n> > optional \"git-old-style\" package that installs many \"git-foo\"\n> > wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n> > People who like the dashed form can keep typing \"git-foo\", even\n> > though that will cost them two exec()s.\n> \n> (C) Just don't do it. Leave the git-foo commands as they were. They\n> weren't actually hurting anyone, and you don't actually _gain_\n> anything by removing them. For those occasional nutters who\n> _really_ care about the size of /usr/bin, give them the _option_\n> of a 'make install' without installing the aliases.\n\nAcked-by: Geert Uytterhoeven \n\nBTW, now we have man pages for deprecated commands that are not in the default\nPATH, which are showing examples for deprecated commands that are not in the\ndefault PATH?\n\nWith kind regards,\n\nGeert Uytterhoeven\nSoftware Architect\n\nSony Techsoft Centre Europe\nThe Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium\n\nPhone: +32 (0)2 700 8453\nFax: +32 (0)2 700 8622\nE-mail: Geert.Uytterhoeven@sonycom.com\nInternet: http://www.sony-europe.com/\n\nA division of Sony Europe (Belgium) N.V.\nVAT BE 0413.825.160 · RPR Brussels\nFortis · BIC GEBABEBB · IBAN BE41293037680010"},{"id":"88449","messageId":"20080825124341.GD26610@one.firstfloor.org","threadId":"15184","inReplyTo":"1219664940.9583.42.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-25T12:43:41Z","receivedAt":"2008-08-25T12:43:41Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"> (C) Just don't do it. Leave the git-foo commands as they were. They\n> weren't actually hurting anyone, and you don't actually _gain_\n> anything by removing them. For those occasional nutters who\n> _really_ care about the size of /usr/bin, give them the _option_\n> of a 'make install' without installing the aliases.\n\n(Ca) Only leave the widely used commands in $PATH and remove the ones\nwhich are mostly used by internal scripts only.\n\n-Andi\n"},{"id":"88453","messageId":"48B2B21B.1080203@canonical.com","threadId":"15184","inReplyTo":"1219664940.9583.42.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Ben Collins","fromEmail":"ben.collins@canonical.com","sentAt":"2008-08-25T13:22:35Z","receivedAt":"2008-08-25T13:22:35Z","isPatch":false,"sender":{"key":"ben.collins@canonical.com","avatar":null},"body":"David Woodhouse wrote:\n> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:\n>> There is one alternative, and one augmentation:\n>>\n>> (A) We do not do anything.\n>>\n>> (B) In addition to the main transition plan, outside git, prepare an\n>> optional \"git-old-style\" package that installs many \"git-foo\"\n>> wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n>> People who like the dashed form can keep typing \"git-foo\", even\n>> though that will cost them two exec()s.\n> \n> (C) Just don't do it. Leave the git-foo commands as they were. They\n> weren't actually hurting anyone, and you don't actually _gain_\n> anything by removing them. For those occasional nutters who\n> _really_ care about the size of /usr/bin, give them the _option_\n> of a 'make install' without installing the aliases.\n> \n> (Oh look, my /usr/bin has 3806 files in it. And except when I\n> accidentally point the $%#@&! GNOME file dialog box at it, I don't\n> _care_.)\n> \n\nI'll second that. I've not heard a good argument against the git-foo \ncommands. If they were going to be deprecated, it should have actually \nhappened a long time ago.\n\n-- BenC, late to the discussion as usual\n"},{"id":"88463","messageId":"94a0d4530808250738q241b541dpd329b972778039cb@mail.gmail.com","threadId":"15184","inReplyTo":"48B2B21B.1080203@canonical.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-25T14:38:38Z","receivedAt":"2008-08-25T14:38:38Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Aug 25, 2008 at 4:22 PM, Ben Collins wrote:\n> David Woodhouse wrote:\n>>\n>> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:\n>>>\n>>> There is one alternative, and one augmentation:\n>>>\n>>> (A) We do not do anything.\n>>>\n>>> (B) In addition to the main transition plan, outside git, prepare an\n>>> optional \"git-old-style\" package that installs many \"git-foo\"\n>>> wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\".\n>>> People who like the dashed form can keep typing \"git-foo\", even\n>>> though that will cost them two exec()s.\n>>\n>> (C) Just don't do it. Leave the git-foo commands as they were. They\n>> weren't actually hurting anyone, and you don't actually _gain_\n>> anything by removing them. For those occasional nutters who\n>> _really_ care about the size of /usr/bin, give them the _option_\n>> of a 'make install' without installing the aliases.\n>>\n>> (Oh look, my /usr/bin has 3806 files in it. And except when I\n>> accidentally point the $%#@&! GNOME file dialog box at it, I don't\n>> _care_.)\n>>\n>\n> I'll second that. I've not heard a good argument against the git-foo\n> commands. If they were going to be deprecated, it should have actually\n> happened a long time ago.\n\nI personally like to use the git- format in written discussions\nregarding git stuff (git-status vs git status), and for man.\n\nI rarely do ls on /usr/bin, so I don't care if there are thousands of\ngit-whatever files there (thought exec-path somehow feels right), but\nI can see how that could be an issue for people with minimal systems\nor in different platforms with no hardlinks (win32 on fat32). But in\nthose cases aliases can be used: git-whatever -> \"git whatever\".\n\nSo I agree, there's no valid reason to remove the git-whatever stuff,\nactually for documentation it does makes sense to me.\n\nBest regards.\n\n-- \nFelipe Contreras\n"},{"id":"88483","messageId":"alpine.DEB.1.00.0808252018490.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15184","inReplyTo":"1219664940.9583.42.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-25T18:19:49Z","receivedAt":"2008-08-25T18:19:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 25 Aug 2008, David Woodhouse wrote:\n\n> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:\n> > \n> > There is one alternative, and one augmentation:\n> > \n> > (A) We do not do anything.\n> > \n> > (B) In addition to the main transition plan, outside git, prepare an\n> > optional \"git-old-style\" package that installs many \"git-foo\" \n> > wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\". \n> > People who like the dashed form can keep typing \"git-foo\", even \n> > though that will cost them two exec()s.\n> \n> (C) Just don't do it. Leave the git-foo commands as they were. They\n> weren't actually hurting anyone, and you don't actually _gain_\n> anything by removing them.\n\nUmm. What exactly makes you feel you should ignore the discussions we had \naround the issues on the git and msysgit mailing list?\n\nCiao,\nDscho\n"},{"id":"88526","messageId":"7vy72kek6y.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"alpine.DEB.1.00.0808252018490.24820@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-25T23:41:57Z","receivedAt":"2008-08-25T23:41:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 25 Aug 2008, David Woodhouse wrote:\n>\n>> On Sat, 2008-08-23 at 20:33 -0700, Junio C Hamano wrote:\n>> > \n>> > There is one alternative, and one augmentation:\n>> > \n>> > (A) We do not do anything.\n>> > \n>> > (B) In addition to the main transition plan, outside git, prepare an\n>> > optional \"git-old-style\" package that installs many \"git-foo\" \n>> > wrappers in $PATH (i.e. /usr/bin). Each of them exec \"git foo\". \n>> > People who like the dashed form can keep typing \"git-foo\", even \n>> > though that will cost them two exec()s.\n>> \n>> (C) Just don't do it. Leave the git-foo commands as they were. They\n>> weren't actually hurting anyone, and you don't actually _gain_\n>> anything by removing them.\n>\n> Umm. What exactly makes you feel you should ignore the discussions we had \n> around the issues on the git and msysgit mailing list?\n\nWell, this was partly my fault, as I did not make it clear in this part\nthat beating the horse that has been dead for two years is not a\nproductive way to spend out time. I however did, in the part David did\nnot quote, try to make it clear:\n\n That's all history now anyway. We should try to do better the next time,\n which is much more important, and that is the topic of this message.\n\n Now, we haven't set the timeframe yet, but the original plan, advocated by\n Linus and others, was to eventually stop installing \"git-foo\" form on the\n filesystem for builtin commands. If we were to do this, we should plan\n how the deprecation period for this change should look like. I think the\n sequence of events would look like this:\n\nthat we are now talking about what we can do better from here going\nforward, but these paragraphs were separated from the quoted part that\ndescribes what kind of *variations* are possible in addition to the \"the\nsequence of events would look like this:\" list, and allowed David to make\nan out of context quoting that made a comment on an offtopic tangent look\nas if it were one of the valid alternatives.\n"},{"id":"88534","messageId":"48B3715D.7020608@gmail.com","threadId":"15184","inReplyTo":"1219664940.9583.42.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-08-26T02:58:37Z","receivedAt":"2008-08-26T02:58:37Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"David Woodhouse wrote:\n> \n> (C) Just don't do it. Leave the git-foo commands as they were. They\n> weren't actually hurting anyone, and you don't actually _gain_\n> anything by removing them. For those occasional nutters who\n> _really_ care about the size of /usr/bin, give them the _option_\n> of a 'make install' without installing the aliases.\n\nAcked-by: A Large Angry SCM \n"},{"id":"88535","messageId":"48B371C0.6020203@gmail.com","threadId":"15184","inReplyTo":"20080825124341.GD26610@one.firstfloor.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-08-26T03:00:16Z","receivedAt":"2008-08-26T03:00:16Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Andi Kleen wrote:\n>> (C) Just don't do it. Leave the git-foo commands as they were. They\n>> weren't actually hurting anyone, and you don't actually _gain_\n>> anything by removing them. For those occasional nutters who\n>> _really_ care about the size of /usr/bin, give them the _option_\n>> of a 'make install' without installing the aliases.\n> \n> (Ca) Only leave the widely used commands in $PATH and remove the ones\n> which are mostly used by internal scripts only.\n\nPlease define what you mean by \"widely used\". I define it as \"any git \ncommand I care use\".\n"},{"id":"88552","messageId":"20080826091701.2e4e3ff4@hyperion.delvare","threadId":"15184","inReplyTo":"48B3715D.7020608@gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jean Delvare","fromEmail":"khali@linux-fr.org","sentAt":"2008-08-26T07:17:01Z","receivedAt":"2008-08-26T07:17:01Z","isPatch":false,"sender":{"key":"khali@linux-fr.org","avatar":"https://gravatar.com/avatar/f8d1a5b65d416951f857a72a21321540bc2b4350e1c5243caa0c620f95b01b6e?d=mp&s=160"},"body":"On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:\n> David Woodhouse wrote:\n> > \n> > (C) Just don't do it. Leave the git-foo commands as they were. They\n> > weren't actually hurting anyone, and you don't actually _gain_\n> > anything by removing them. For those occasional nutters who\n> > _really_ care about the size of /usr/bin, give them the _option_\n> > of a 'make install' without installing the aliases.\n> \n> Acked-by: A Large Angry SCM \n\nSuch statements from anonymous people have zero value, sorry.\n\n-- \nJean Delvare\n"},{"id":"88565","messageId":"48B3E517.2040409@gmail.com","threadId":"15184","inReplyTo":"20080826091701.2e4e3ff4@hyperion.delvare","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-08-26T11:12:23Z","receivedAt":"2008-08-26T11:12:23Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Jean Delvare wrote:\n> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:\n>> David Woodhouse wrote:\n>>> (C) Just don't do it. Leave the git-foo commands as they were. They\n>>> weren't actually hurting anyone, and you don't actually _gain_\n>>> anything by removing them. For those occasional nutters who\n>>> _really_ care about the size of /usr/bin, give them the _option_\n>>> of a 'make install' without installing the aliases.\n>> Acked-by: A Large Angry SCM \n> \n> Such statements from anonymous people have zero value, sorry.\n> \n\nDo some research; I haven't been anonymous since 2005.\n"},{"id":"88570","messageId":"48B3EF6B.7070400@s5r6.in-berlin.de","threadId":"15184","inReplyTo":"48B3E517.2040409@gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2008-08-26T11:56:27Z","receivedAt":"2008-08-26T11:56:27Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"A Large Angry SCM wrote:\n> Jean Delvare wrote:\n>> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:\n>>> David Woodhouse wrote:\n>>>> (C) Just don't do it. Leave the git-foo commands as they were. They\n>>>> weren't actually hurting anyone, and you don't actually _gain_\n>>>> anything by removing them. For those occasional nutters who\n>>>> _really_ care about the size of /usr/bin, give them the _option_\n>>>> of a 'make install' without installing the aliases.\n>>> Acked-by: A Large Angry SCM \n[...]\n> Do some research; [...]\n\n...the plan to move git-foo out of /usr/bin has been discussed and \nwrapped up quite a while ago (am I confident to say without being \nsubscriber of git@vger.k'org myself).\n\nInstead of unhelpful complaints after the fact, you could try which of \nthe many available alternatives work for you: Extended PATH, shell \naliases, command line completion setup, links in ~/bin, or so many other \npossibilities of varying degree of sophistication. If none of these fix \nwhatever issues you experience, there is surely opportunity to discuss \ndetails on the git list.\n-- \nStefan Richter\n-=====-==--- =--- ==-=-\nhttp://arcgraph.de/sr/\n"},{"id":"88576","messageId":"1219753622.7107.54.camel@pmac.infradead.org","threadId":"15184","inReplyTo":"7vy72kek6y.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-08-26T12:27:02Z","receivedAt":"2008-08-26T12:27:02Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Mon, 2008-08-25 at 16:41 -0700, Junio C Hamano wrote:\n> Well, this was partly my fault, as I did not make it clear in this part\n> that beating the horse that has been dead for two years is not a\n> productive way to spend out time. I however did, in the part David did\n> not quote, try to make it clear:\n\nDo you have a reference to the previous discussion? In particular, any\npart of it where any _real_ benefits of breaking compatibility are\ngiven.\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"88578","messageId":"20080826142826.GE26523@spearce.org","threadId":"15184","inReplyTo":"48B3E517.2040409@gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-26T14:28:26Z","receivedAt":"2008-08-26T14:28:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"A Large Angry SCM wrote:\n> Jean Delvare wrote:\n>>>\n>>> Acked-by: A Large Angry SCM \n>>\n>> Such statements from anonymous people have zero value, sorry.\n>>\n>\n> Do some research; I haven't been anonymous since 2005.\n\nAt which point one has to ask himself, \"self, why I am still hiding\nbehind an anonymous name?\"\n\n-- \nShawn.\n"},{"id":"88580","messageId":"20080826144624.GA5046@coredump.intra.peff.net","threadId":"15184","inReplyTo":"20080826091701.2e4e3ff4@hyperion.delvare","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-26T14:46:25Z","receivedAt":"2008-08-26T14:46:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 09:17:01AM +0200, Jean Delvare wrote:\n\n> > Acked-by: A Large Angry SCM \n> \n> Such statements from anonymous people have zero value, sorry.\n\nI think it depends on how you define \"anonymous\". I don't know\ngitzilla's legal name, and nor do I care. But I have seen the reputation\nhe or she has established through postings on the git list over the past\nfew years, and that gives the statement non-zero value.\n\nAnd I don't know who _you_ are, even though you are presumably using\nyour real name (probably because this message is cross-posted, and you\nhave some reputation on users@kernel.org, with which I am not familiar).\n\n-Peff\n"},{"id":"88581","messageId":"20080826145719.GB5046@coredump.intra.peff.net","threadId":"15184","inReplyTo":"7vy72kek6y.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-26T14:57:19Z","receivedAt":"2008-08-26T14:57:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:\n\n> > Umm. What exactly makes you feel you should ignore the discussions we had \n> > around the issues on the git and msysgit mailing list?\n> \n> Well, this was partly my fault, as I did not make it clear in this part\n> that beating the horse that has been dead for two years is not a\n> productive way to spend out time. I however did, in the part David did\n> not quote, try to make it clear:\n> \n> That's all history now anyway. We should try to do better the next time,\n> which is much more important, and that is the topic of this message.\n\nI don't want to stir up this discussion too much; I am sure you have\nmany more important things to be working on. But I did want to make one\nobservation.\n\nOne side of the argument, I see a lot of \"I would prefer it this way.\"\nAnd on the other side I see a lot of \"this discussion is already\nhistory\" and \"but I do not care personally that much.\"\n\nIt makes me wonder why nobody has said \"no, really, I prefer it without\nthe programs in /bin.\" Are they simply confident that the decision has\nbeen made, and don't feel the need to say something?\n\nI am just concerned that we are following a path that is not the best\none because \"it was decided\" already, when perhaps:\n\n - the reasons for making that decision may have changed\n\n - the people interested in opposing that decision didn't speak up at\n the time, either because they weren't git users then, weren't as\n active in the mailing list, changed their minds, or were simply too\n lazy to read the release notes\n\nAgain, I don't want to waste time (especially yours, Junio) with a\ndiscussion that is fruitless. But I also don't like to see \"no, you are\nnot allowed to bring fresh arguments to this decision\". That precludes\nthe possibility that the decision was wrong.\n\nMaybe the people who want to keep git-* can discuss amongst themselves\n(on the list, but the rest of us can ignore it) and present a concise\nargument why circumstances around this decision may have changed.\n\n-Peff\n"},{"id":"88583","messageId":"1219764860.4471.13.camel@gaara.bos.redhat.com","threadId":"15184","inReplyTo":"20080826145719.GB5046@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Kristian Høgsberg","fromEmail":"krh@redhat.com","sentAt":"2008-08-26T15:34:20Z","receivedAt":"2008-08-26T15:34:20Z","isPatch":false,"sender":{"key":"krh@redhat.com","avatar":"https://gravatar.com/avatar/763dee6f9594ac474f725b137a39565792928e583ddf59b32befc2907409027e?d=mp&s=160"},"body":"On Tue, 2008-08-26 at 10:57 -0400, Jeff King wrote:\n> On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:\n> \n> > > Umm. What exactly makes you feel you should ignore the discussions we had \n> > > around the issues on the git and msysgit mailing list?\n> > \n> > Well, this was partly my fault, as I did not make it clear in this part\n> > that beating the horse that has been dead for two years is not a\n> > productive way to spend out time. I however did, in the part David did\n> > not quote, try to make it clear:\n> > \n> > That's all history now anyway. We should try to do better the next time,\n> > which is much more important, and that is the topic of this message.\n> \n> I don't want to stir up this discussion too much; I am sure you have\n> many more important things to be working on. But I did want to make one\n> observation.\n> \n> One side of the argument, I see a lot of \"I would prefer it this way.\"\n> And on the other side I see a lot of \"this discussion is already\n> history\" and \"but I do not care personally that much.\"\n> \n> It makes me wonder why nobody has said \"no, really, I prefer it without\n> the programs in /bin.\" Are they simply confident that the decision has\n> been made, and don't feel the need to say something?\n\nIt's pretty normal to see opponents of a decision like this complain\nloudly when it lands on their system, whereas the silent majority in\nfavour will be happy to see the change finally implemented but reluctant\nto stir up the discussion again.\n\nI don't think new arguments are brought to the discussion, just new\npeople, who are temporarily inconvened by a change towards sanity.\n\nKristian\n"},{"id":"88584","messageId":"1219766398.7107.87.camel@pmac.infradead.org","threadId":"15184","inReplyTo":"1219764860.4471.13.camel@gaara.bos.redhat.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-08-26T15:59:58Z","receivedAt":"2008-08-26T15:59:58Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n> It's pretty normal to see opponents of a decision like this complain\n> loudly when it lands on their system, whereas the silent majority in\n> favour will be happy to see the change finally implemented but reluctant\n> to stir up the discussion again.\n> \n> I don't think new arguments are brought to the discussion, just new\n> people, who are temporarily inconvened by a change towards sanity.\n\nNice emotive response, especially the subtle but unsubstantiated 'silent\nmajority in favour' bit -- but you forgot the part where you were\nsupposed to actually point out a tangible benefit which is achieved by\nbreaking compatibility like this.\n\nAnd no, reducing the size of /usr/bin by a tiny fraction isn't really a\nworthwhile benefit -- in reality, the 'silent majority' really couldn't\ngive a monkey's left testicle about that, and breakage caused by the\ngratuitous change _far_ outweighs any minuscule improvement.\n\nIt's particularly silly because we could have just made these aliases\noptional but present by default, so those few nutters who _really_ spend\ntheir days worrying about such stuff can do without them.\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"88585","messageId":"1f6632e50808260904t6bea0be5kc69342917e3db97@mail.gmail.com","threadId":"15184","inReplyTo":"1219766398.7107.87.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthias Kestenholz","fromEmail":"mk@spinlock.ch","sentAt":"2008-08-26T16:04:00Z","receivedAt":"2008-08-26T16:04:00Z","isPatch":false,"sender":{"key":"matthias@spinlock.ch","avatar":"https://gravatar.com/avatar/bc18f396e70163d09ab458a341b1decb7e8b6ee3aa2c0c954ec20162e67c4d46?d=mp&s=160"},"body":"On Tue, Aug 26, 2008 at 5:59 PM, David Woodhouse wrote:\n> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n>> It's pretty normal to see opponents of a decision like this complain\n>> loudly when it lands on their system, whereas the silent majority in\n>> favour will be happy to see the change finally implemented but reluctant\n>> to stir up the discussion again.\n>>\n>> I don't think new arguments are brought to the discussion, just new\n>> people, who are temporarily inconvened by a change towards sanity.\n>\n> Nice emotive response, especially the subtle but unsubstantiated 'silent\n> majority in favour' bit -- but you forgot the part where you were\n> supposed to actually point out a tangible benefit which is achieved by\n> breaking compatibility like this.\n>\n> And no, reducing the size of /usr/bin by a tiny fraction isn't really a\n> worthwhile benefit -- in reality, the 'silent majority' really couldn't\n> give a monkey's left testicle about that, and breakage caused by the\n> gratuitous change _far_ outweighs any minuscule improvement.\n>\n\nCorrect, but there is a benefit. Imagine a new user:\n\ngit- ... what? 140-something commands? I'll better start looking\nfor alternatives _right now_!\n\nHaving a cluttered namespace is never a good thing. It means that it's\nless obvious which commands you are supposed to use etc.\n"},{"id":"88587","messageId":"1219767455.5493.4.camel@gaara.bos.redhat.com","threadId":"15184","inReplyTo":"1219766398.7107.87.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Kristian Høgsberg","fromEmail":"krh@redhat.com","sentAt":"2008-08-26T16:17:35Z","receivedAt":"2008-08-26T16:17:35Z","isPatch":false,"sender":{"key":"krh@redhat.com","avatar":"https://gravatar.com/avatar/763dee6f9594ac474f725b137a39565792928e583ddf59b32befc2907409027e?d=mp&s=160"},"body":"On Tue, 2008-08-26 at 16:59 +0100, David Woodhouse wrote:\n> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n> > It's pretty normal to see opponents of a decision like this complain\n> > loudly when it lands on their system, whereas the silent majority in\n> > favour will be happy to see the change finally implemented but reluctant\n> > to stir up the discussion again.\n> > \n> > I don't think new arguments are brought to the discussion, just new\n> > people, who are temporarily inconvened by a change towards sanity.\n> \n> Nice emotive response, especially the subtle but unsubstantiated 'silent\n> majority in favour' bit -- but you forgot the part where you were\n> supposed to actually point out a tangible benefit which is achieved by\n> breaking compatibility like this.\n\nOh get off your high horse, this entire thread is pretty much all\nbullshit and emotions. Not every arbitrary decision deserves to be set\nin stone and be defended under the banner of backwards compatibility.\n\nKristian\n"},{"id":"88588","messageId":"20080826182349.0a1a75e2@hyperion.delvare","threadId":"15184","inReplyTo":"1219766398.7107.87.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jean Delvare","fromEmail":"khali@linux-fr.org","sentAt":"2008-08-26T16:23:49Z","receivedAt":"2008-08-26T16:23:49Z","isPatch":false,"sender":{"key":"khali@linux-fr.org","avatar":"https://gravatar.com/avatar/f8d1a5b65d416951f857a72a21321540bc2b4350e1c5243caa0c620f95b01b6e?d=mp&s=160"},"body":"On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:\n> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n> > It's pretty normal to see opponents of a decision like this complain\n> > loudly when it lands on their system, whereas the silent majority in\n> > favour will be happy to see the change finally implemented but reluctant\n> > to stir up the discussion again.\n> > \n> > I don't think new arguments are brought to the discussion, just new\n> > people, who are temporarily inconvened by a change towards sanity.\n> \n> Nice emotive response, especially the subtle but unsubstantiated 'silent\n> majority in favour' bit -- but you forgot the part where you were\n> supposed to actually point out a tangible benefit which is achieved by\n> breaking compatibility like this.\n> \n> And no, reducing the size of /usr/bin by a tiny fraction isn't really a\n> worthwhile benefit -- in reality, the 'silent majority' really couldn't\n> give a monkey's left testicle about that, and breakage caused by the\n> gratuitous change _far_ outweighs any minuscule improvement.\n\nReducing /usr/bin in size was totally worthwhile. Maybe not to you, but\nto the silent majority I am a proud member of, it was. (I'm not saying\nthat the path that was taken to get there was optimal, just that the\ngoal was sound.)\n\nI just can't think of any other tool which installs over 100 binaries\n(or scripts, that's the same) in /usr/bin. Can you? This is simply\ninsane. If all tools did what git did, you'd have maybe 100,000 files\nin /usr/bin (that is, if your filesystem supports that) and your system\nwould be pretty slow. So I'm very glad to see git come back to reason.\nIf nothing else, just so that other tool authors don't think it's the\nright way to do it.\n\n> It's particularly silly because we could have just made these aliases\n> optional but present by default, so those few nutters who _really_ spend\n> their days worrying about such stuff can do without them.\n\n\n-- \nJean Delvare\n"},{"id":"88589","messageId":"20080826162513.GR10544@machine.or.cz","threadId":"15184","inReplyTo":"1f6632e50808260904t6bea0be5kc69342917e3db97@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-26T16:25:13Z","receivedAt":"2008-08-26T16:25:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:\n> Correct, but there is a benefit. Imagine a new user:\n> \n> git- ... what? 140-something commands? I'll better start looking\n> for alternatives _right now_!\n\nActually, this is the only realistic argument I can remember at all.\nAre there any others? I couldn't come up with any - but I didn't do much\nhistory digging: others seem to be equally in dark, though.\n\n(And I'm not saying this one is not important; it's apparently a\nsignificant \"P.R.\" issue. But is just this _the_ official rationale?)\n\n> Having a cluttered namespace is never a good thing. It means that it's\n> less obvious which commands you are supposed to use etc.\n\nThis is not much of a valid argument; you could install the same set of\ncommands to /usr/bin that you are offering in the bash autocompletion.\n(With the catch that this might break peoples scripts in a subtler way\nthan just removing all of them.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"88592","messageId":"20080826164526.GM26610@one.firstfloor.org","threadId":"15184","inReplyTo":"20080826162513.GR10544@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-26T16:45:26Z","receivedAt":"2008-08-26T16:45:26Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:\n> On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:\n> > Correct, but there is a benefit. Imagine a new user:\n> > \n> > git- ... what? 140-something commands? I'll better start looking\n> > for alternatives _right now_!\n> \n> Actually, this is the only realistic argument I can remember at all.\n\nIt's not very convincing, because the bash completions script file for git \nis installed by default[1] which completes both forms, so the new user will \nexperience instead:\n\ngit.... what? 140-something commands? etc.etc.\n\nSomeone didn't think this through?\n\nI won't disagree that the 140 commands thing is a problem -- I remember\nthinking the same thoughts and I am still scared occasionally by\nthe multitude of commands. But that doesn't seem to be the solution.\n\n-Andi\n\n[1] At least it's in my openSUSE build service git-core rpm by default.\n"},{"id":"88593","messageId":"s5hvdxnlnzi.wl%tiwai@suse.de","threadId":"15184","inReplyTo":"20080826182349.0a1a75e2@hyperion.delvare","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Takashi Iwai","fromEmail":"tiwai@suse.de","sentAt":"2008-08-26T16:50:25Z","receivedAt":"2008-08-26T16:50:25Z","isPatch":false,"sender":{"key":"tiwai@suse.de","avatar":"https://avatars.githubusercontent.com/u/306482?v=4"},"body":"At Tue, 26 Aug 2008 18:23:49 +0200,\nJean Delvare wrote:\n> \n> On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:\n> > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n> > > It's pretty normal to see opponents of a decision like this complain\n> > > loudly when it lands on their system, whereas the silent majority in\n> > > favour will be happy to see the change finally implemented but reluctant\n> > > to stir up the discussion again.\n> > > \n> > > I don't think new arguments are brought to the discussion, just new\n> > > people, who are temporarily inconvened by a change towards sanity.\n> > \n> > Nice emotive response, especially the subtle but unsubstantiated 'silent\n> > majority in favour' bit -- but you forgot the part where you were\n> > supposed to actually point out a tangible benefit which is achieved by\n> > breaking compatibility like this.\n> > \n> > And no, reducing the size of /usr/bin by a tiny fraction isn't really a\n> > worthwhile benefit -- in reality, the 'silent majority' really couldn't\n> > give a monkey's left testicle about that, and breakage caused by the\n> > gratuitous change _far_ outweighs any minuscule improvement.\n> \n> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but\n> to the silent majority I am a proud member of, it was. (I'm not saying\n> that the path that was taken to get there was optimal, just that the\n> goal was sound.)\n> \n> I just can't think of any other tool which installs over 100 binaries\n> (or scripts, that's the same) in /usr/bin. Can you?\n\nnetpbm has almost 300 in /usr/bin.\n\n\nTakashi\n"},{"id":"88598","messageId":"alpine.LFD.1.10.0808260959000.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"1219766398.7107.87.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-26T17:03:25Z","receivedAt":"2008-08-26T17:03:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Aug 2008, David Woodhouse wrote:\n> \n> Nice emotive response, especially the subtle but unsubstantiated 'silent\n> majority in favour' bit -- but you forgot the part where you were\n> supposed to actually point out a tangible benefit which is achieved by\n> breaking compatibility like this.\n\nUmm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty \nmuch day#1. The number of people complaining about it going away has \nliterally been _much_ smaller than the people who complained about it \nbeing there.\n\nAlso, like it or not, it's done. So the argument about \"compatibility\" is \nTOTAL AND UTTER BULLSHIT. There is no compatibility, because we already \nreleased a major version without them.\n\nSo live with it, and just add the \n\n\tPATH=\"$PATH:$(git --exec-path)\"\n\nas a \"compatibility layer\" to your own setup already. There is no \ndownside, and I think there _is_ a big upside, and no, it's not just about \n\"/usr/bin\" being smaller.\n\nIn case you wonder, the upside is:\n\n - new people don't even learn the mistakes\n\n - the people who _did_ complain are happier\n\n - this model allows a per-user-preference model even on the same machine \n (ie even on something like master.kernel.org, everybody can choose \n _individually_ whether they want to see 'git-xyzzy' or not!)\n\nand there really is zero downside apart from the _trivial_ downside of you \njust having to add a single PATH thing to your .bashrc or something.\n\n\t\t\tLinus\n"},{"id":"88596","messageId":"20080826170446.GA5318@coredump.intra.peff.net","threadId":"15184","inReplyTo":"20080826164526.GM26610@one.firstfloor.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-26T17:04:46Z","receivedAt":"2008-08-26T17:04:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:\n\n> It's not very convincing, because the bash completions script file for git \n> is installed by default[1] which completes both forms, so the new user will \n> experience instead:\n> \n> git.... what? 140-something commands? etc.etc.\n\nThe bash completion has the luxury of not mentioning some commands if\nthey are likely to be confusing (i.e., very low-level plumbing).\n\nThat being said, it still produces 70-something commands.\n\n-Peff\n"},{"id":"88600","messageId":"alpine.LFD.1.10.0808261004150.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"20080826164526.GM26610@one.firstfloor.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-26T17:05:57Z","receivedAt":"2008-08-26T17:05:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Aug 2008, Andi Kleen wrote:\n> \n> It's not very convincing, because the bash completions script file for git \n> is installed by default[1] which completes both forms, so the new user will \n> experience instead:\n> \n> git.... what? 140-something commands? etc.etc.\n\nNo. \n\nYour argument makes no sense.\n\nWhen you do\n\n\tls\n\nand it says\n\n\tDisplay all 122 possibilities? (y or n)\n\n(yeah, my home directory is a mess) do you really think \"What? \n120-something commands? etc etc\".\n\nHell no, you don't.\n\nThere's a big difference between having the space and not having it, and \nanybody who argues otherwise is being dishonest.\n\n\t\tLinus\n"},{"id":"88597","messageId":"20080826170748.GB5318@coredump.intra.peff.net","threadId":"15184","inReplyTo":"20080826162513.GR10544@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-26T17:07:48Z","receivedAt":"2008-08-26T17:07:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:\n\n> > git- ... what? 140-something commands? I'll better start looking\n> > for alternatives _right now_!\n> \n> Actually, this is the only realistic argument I can remember at all.\n> Are there any others? I couldn't come up with any - but I didn't do much\n> history digging: others seem to be equally in dark, though.\n\nThe three reasons I can recall are:\n\n - too many commands on completion\n\n - confusion between \"git-*\" and \"git *\" equivalence, and inability to\n perform some operations with \"git-*\" (like git --no-pager).\n\n - I might be wrong, but I think there was discussion of a\n hardlink-challenged platform where we wasted space by copying the\n 'git' binary. Taking git-* out of /usr/bin is the first step to\n removing the hardlinks entirely.\n\n-Peff\n"},{"id":"88599","messageId":"20080826171012.GO10360@machine.or.cz","threadId":"15184","inReplyTo":"20080826164526.GM26610@one.firstfloor.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-26T17:10:12Z","receivedAt":"2008-08-26T17:10:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:\n> On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:\n> > On Tue, Aug 26, 2008 at 06:04:00PM +0200, Matthias Kestenholz wrote:\n> > > Correct, but there is a benefit. Imagine a new user:\n> > > \n> > > git- ... what? 140-something commands? I'll better start looking\n> > > for alternatives _right now_!\n> > \n> > Actually, this is the only realistic argument I can remember at all.\n> \n> It's not very convincing, because the bash completions script file for git \n> is installed by default[1] which completes both forms, so the new user will \n> experience instead:\n> \n> git.... what? 140-something commands? etc.etc.\n\nNo, the point of course is that you should get much less.\n\nIt offers 66 commands to me here, though it's still way too many - some\nof them are clearly plumbing: count-objects, ls-tree, checkout-index?\nSomeone should submit a patch! ;-) (After eliminating these, this comes\ndown to 56 commands - which is still a lot, but the numbers are getting\nsomewhat sane already.)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"88604","messageId":"20080826171144.21328.82727.stgit@localhost","threadId":"15184","inReplyTo":"20080826171012.GO10360@machine.or.cz","subject":"[PATCH] bash completion: Hide more plumbing commands","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-26T17:11:44Z","receivedAt":"2008-08-26T17:11:44Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"git still shows way too many commands, some of them\nare clearly plumbing. This patch hides the plumbing commands\nliberally (that is, in special cases, users still might want to\ncall one of the hidden commands, a *normal* workflow should never\ninvolve these, though - and if it does, we have a UI problem anyway).\n\nSigned-off-by: Petr Baudis \n---\n\n contrib/completion/git-completion.bash | 10 ++++++++++\n 1 files changed, 10 insertions(+), 0 deletions(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 89858c2..773d64b 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -386,7 +386,9 @@ __git_porcelain_commands ()\n \t\tcat-file) : plumbing;;\n \t\tcheck-attr) : plumbing;;\n \t\tcheck-ref-format) : plumbing;;\n+\t\tcheckout-index) : plumbing;;\n \t\tcommit-tree) : plumbing;;\n+\t\tcount-objects) : plumbing;;\n \t\tcvsexportcommit) : export;;\n \t\tcvsimport) : import;;\n \t\tcvsserver) : daemon;;\n@@ -395,6 +397,7 @@ __git_porcelain_commands ()\n \t\tdiff-index) : plumbing;;\n \t\tdiff-tree) : plumbing;;\n \t\tfast-import) : import;;\n+\t\tfast-export) : export;;\n \t\tfsck-objects) : plumbing;;\n \t\tfetch-pack) : plumbing;;\n \t\tfmt-merge-msg) : plumbing;;\n@@ -404,6 +407,10 @@ __git_porcelain_commands ()\n \t\tindex-pack) : plumbing;;\n \t\tinit-db) : deprecated;;\n \t\tlocal-fetch) : plumbing;;\n+\t\tlost-found) : deprecated;;\n+\t\tls-files) : plumbing;;\n+\t\tls-remote) : plumbing;;\n+\t\tls-tree) : plumbing;;\n \t\tmailinfo) : plumbing;;\n \t\tmailsplit) : plumbing;;\n \t\tmerge-*) : plumbing;;\n@@ -428,6 +435,7 @@ __git_porcelain_commands ()\n \t\trunstatus) : plumbing;;\n \t\tsh-setup) : internal;;\n \t\tshell) : daemon;;\n+\t\tshow-ref) : plumbing;;\n \t\tsend-pack) : plumbing;;\n \t\tshow-index) : plumbing;;\n \t\tssh-*) : transport;;\n@@ -442,6 +450,8 @@ __git_porcelain_commands ()\n \t\tupload-archive) : plumbing;;\n \t\tupload-pack) : plumbing;;\n \t\twrite-tree) : plumbing;;\n+\t\tvar) : plumbing;;\n+\t\tverify-pack) : plumbing;;\n \t\tverify-tag) : plumbing;;\n \t\t*) echo $i;;\n \t\tesac\n"},{"id":"88601","messageId":"20080826171255.GI26523@spearce.org","threadId":"15184","inReplyTo":"20080826171012.GO10360@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-26T17:12:55Z","receivedAt":"2008-08-26T17:12:55Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> On Tue, Aug 26, 2008 at 06:45:26PM +0200, Andi Kleen wrote:\n> > \n> > It's not very convincing, because the bash completions script file for git \n> > is installed by default[1] which completes both forms, so the new user will \n> > experience instead:\n> > \n> > git.... what? 140-something commands? etc.etc.\n> \n> No, the point of course is that you should get much less.\n> \n> It offers 66 commands to me here, though it's still way too many - some\n> of them are clearly plumbing: count-objects, ls-tree, checkout-index?\n> Someone should submit a patch! ;-) (After eliminating these, this comes\n> down to 56 commands - which is still a lot, but the numbers are getting\n> somewhat sane already.)\n\nI'm the reason why count-objects, ls-tree and checkout-index are\nstill offered by the bash completion. And sitting here reading your\nemail I realized its been _months_ since I last called checkout-index\nby hand. I still run count-objects and ls-tree very so often, but the\naverage user probably doesn't use ls-tree.\n\nSo yea, these probably should be removed from the completion list.\nBut I can make a weak argument for keeping count-objects.\n\n-- \nShawn.\n"},{"id":"88602","messageId":"20080826171623.GE5318@coredump.intra.peff.net","threadId":"15184","inReplyTo":"20080826171255.GI26523@spearce.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-26T17:16:24Z","receivedAt":"2008-08-26T17:16:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:\n\n> I'm the reason why count-objects, ls-tree and checkout-index are\n> still offered by the bash completion. And sitting here reading your\n> email I realized its been _months_ since I last called checkout-index\n> by hand. I still run count-objects and ls-tree very so often, but the\n> average user probably doesn't use ls-tree.\n> \n> So yea, these probably should be removed from the completion list.\n> But I can make a weak argument for keeping count-objects.\n\nI think this message shows the conflict in setting up such a list. We\nwant the command set to be as tiny as possible to help new users find\ntheir way. But we want the command set to be useful to git power users.\n\nI wonder if there should be multiple sets of commands for completion,\nwith a minimal set enabled by default, and a \"power user\" set that\nexposes extra commands. I dunno. Maybe that is overengineering. I don't\neven use the bash completion at all.\n\n-Peff\n"},{"id":"88603","messageId":"20080826192039.5ffa6eec@hyperion.delvare","threadId":"15184","inReplyTo":"s5hvdxnlnzi.wl%tiwai@suse.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jean Delvare","fromEmail":"khali@linux-fr.org","sentAt":"2008-08-26T17:20:39Z","receivedAt":"2008-08-26T17:20:39Z","isPatch":false,"sender":{"key":"khali@linux-fr.org","avatar":"https://gravatar.com/avatar/f8d1a5b65d416951f857a72a21321540bc2b4350e1c5243caa0c620f95b01b6e?d=mp&s=160"},"body":"On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:\n> At Tue, 26 Aug 2008 18:23:49 +0200,\n> Jean Delvare wrote:\n> > \n> > On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:\n> > > On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n> > > > It's pretty normal to see opponents of a decision like this complain\n> > > > loudly when it lands on their system, whereas the silent majority in\n> > > > favour will be happy to see the change finally implemented but reluctant\n> > > > to stir up the discussion again.\n> > > > \n> > > > I don't think new arguments are brought to the discussion, just new\n> > > > people, who are temporarily inconvened by a change towards sanity.\n> > > \n> > > Nice emotive response, especially the subtle but unsubstantiated 'silent\n> > > majority in favour' bit -- but you forgot the part where you were\n> > > supposed to actually point out a tangible benefit which is achieved by\n> > > breaking compatibility like this.\n> > > \n> > > And no, reducing the size of /usr/bin by a tiny fraction isn't really a\n> > > worthwhile benefit -- in reality, the 'silent majority' really couldn't\n> > > give a monkey's left testicle about that, and breakage caused by the\n> > > gratuitous change _far_ outweighs any minuscule improvement.\n> > \n> > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but\n> > to the silent majority I am a proud member of, it was. (I'm not saying\n> > that the path that was taken to get there was optimal, just that the\n> > goal was sound.)\n> > \n> > I just can't think of any other tool which installs over 100 binaries\n> > (or scripts, that's the same) in /usr/bin. Can you?\n> \n> netpbm has almost 300 in /usr/bin.\n\nOuch. (I guess I shouldn't have asked.)\n\nDoes netpbm do anything convert (ImageMagick) doesn't? I'd be happy to\nget rid of netpbm.\n\n(Sorry for getting off-topic.)\n\n-- \nJean Delvare\n"},{"id":"88605","messageId":"20080826172410.GJ26523@spearce.org","threadId":"15184","inReplyTo":"20080826171144.21328.82727.stgit@localhost","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-26T17:24:10Z","receivedAt":"2008-08-26T17:24:10Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Petr Baudis wrote:\n> git still shows way too many commands, some of them\n> are clearly plumbing. This patch hides the plumbing commands\n> liberally (that is, in special cases, users still might want to\n> call one of the hidden commands, a *normal* workflow should never\n> involve these, though - and if it does, we have a UI problem anyway).\n> \n> Signed-off-by: Petr Baudis \n\nAcked-by: Shawn O. Pearce \n\nThough I use git ls-remote at least once every other day to see\nwhat branches are available on my egit/spearce.git fork. Its ok,\nI guess I can type a few extra characters...\n\n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 89858c2..773d64b 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -386,7 +386,9 @@ __git_porcelain_commands ()\n> \t\tcat-file) : plumbing;;\n> \t\tcheck-attr) : plumbing;;\n> \t\tcheck-ref-format) : plumbing;;\n> +\t\tcheckout-index) : plumbing;;\n> \t\tcommit-tree) : plumbing;;\n> +\t\tcount-objects) : plumbing;;\n> \t\tcvsexportcommit) : export;;\n> \t\tcvsimport) : import;;\n> \t\tcvsserver) : daemon;;\n> @@ -395,6 +397,7 @@ __git_porcelain_commands ()\n> \t\tdiff-index) : plumbing;;\n> \t\tdiff-tree) : plumbing;;\n> \t\tfast-import) : import;;\n> +\t\tfast-export) : export;;\n> \t\tfsck-objects) : plumbing;;\n> \t\tfetch-pack) : plumbing;;\n> \t\tfmt-merge-msg) : plumbing;;\n> @@ -404,6 +407,10 @@ __git_porcelain_commands ()\n> \t\tindex-pack) : plumbing;;\n> \t\tinit-db) : deprecated;;\n> \t\tlocal-fetch) : plumbing;;\n> +\t\tlost-found) : deprecated;;\n> +\t\tls-files) : plumbing;;\n> +\t\tls-remote) : plumbing;;\n> +\t\tls-tree) : plumbing;;\n> \t\tmailinfo) : plumbing;;\n> \t\tmailsplit) : plumbing;;\n> \t\tmerge-*) : plumbing;;\n> @@ -428,6 +435,7 @@ __git_porcelain_commands ()\n> \t\trunstatus) : plumbing;;\n> \t\tsh-setup) : internal;;\n> \t\tshell) : daemon;;\n> +\t\tshow-ref) : plumbing;;\n> \t\tsend-pack) : plumbing;;\n> \t\tshow-index) : plumbing;;\n> \t\tssh-*) : transport;;\n> @@ -442,6 +450,8 @@ __git_porcelain_commands ()\n> \t\tupload-archive) : plumbing;;\n> \t\tupload-pack) : plumbing;;\n> \t\twrite-tree) : plumbing;;\n> +\t\tvar) : plumbing;;\n> +\t\tverify-pack) : plumbing;;\n> \t\tverify-tag) : plumbing;;\n> \t\t*) echo $i;;\n> \t\tesac\n\n-- \nShawn.\n"},{"id":"88606","messageId":"20080826172742.GN26610@one.firstfloor.org","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261004150.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andi Kleen","fromEmail":"andi@firstfloor.org","sentAt":"2008-08-26T17:27:42Z","receivedAt":"2008-08-26T17:27:42Z","isPatch":false,"sender":{"key":"andi@firstfloor.org","avatar":null},"body":"> When you do\n> \n> \tls\n\nActually do ls -- and you can well be scared too. \nPerhaps it's not quite git class yet, but it's working on it.\nI could imagine some Unix newbie be scared about that.\n\n[\"Quick: mention the two characters not used as ls short options yet\"]\n\n> \n> and it says\n> \n> \tDisplay all 122 possibilities? (y or n)\n> \n> (yeah, my home directory is a mess)\n\nIt's quite tidy in fact :)\n\n% ls \nDisplay all 584 possibilities? (y or n)\n\n> 120-something commands? etc etc\".\n\nI was assuming someone thinking about using git. At some point\nthey will do the git thing and be scared away.\n\nOk maybe it's not the first action, but it's likely in the first 10 \nminutes; more or less once they discover that git has sub commands.\n\nAnyways the real solution to that is either having less commands\nor hiding the internal ones better. I think both would be fine,\nbut once that is done and there's a slimmed down non scary list,\nthere's no reason to not put the remaining non internal ones back \ninto $PATH isn't it?\n\n-Andi\n"},{"id":"88608","messageId":"80myizelcw.fsf@tiny.isode.net","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808260959000.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Bruce Stephens","fromEmail":"bruce.stephens@isode.com","sentAt":"2008-08-26T17:29:03Z","receivedAt":"2008-08-26T17:29:03Z","isPatch":false,"sender":{"key":"bruce.stephens@isode.com","avatar":null},"body":"Linus Torvalds writes:\n\n[...]\n\n> In case you wonder, the upside is:\n>\n> - new people don't even learn the mistakes\n>\n> - the people who _did_ complain are happier\n>\n> - this model allows a per-user-preference model even on the same machine \n> (ie even on something like master.kernel.org, everybody can choose \n> _individually_ whether they want to see 'git-xyzzy' or not!)\n\nAnd\n\n - it means git aliases have the same form as builtins\n\n - it means git on Windows has the same interface\n\n(Arguably the latter point ought to be \"forces Unix users to use the\nsame interface as on Windows\", but the git-foo forms have been\ndeprecated on all platforms for a while. Making Unix and Windows the\nsame seems a worthwhile goal, though presumably it's irrelevant for\nlinux kernel people.)\n"},{"id":"88609","messageId":"s5h1w0bhe9j.wl%tiwai@suse.de","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808260959000.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Takashi Iwai","fromEmail":"tiwai@suse.de","sentAt":"2008-08-26T17:34:00Z","receivedAt":"2008-08-26T17:34:00Z","isPatch":false,"sender":{"key":"tiwai@suse.de","avatar":"https://avatars.githubusercontent.com/u/306482?v=4"},"body":"At Tue, 26 Aug 2008 10:03:25 -0700 (PDT),\nLinus Torvalds wrote:\n> \n> \n> \n> On Tue, 26 Aug 2008, David Woodhouse wrote:\n> > \n> > Nice emotive response, especially the subtle but unsubstantiated 'silent\n> > majority in favour' bit -- but you forgot the part where you were\n> > supposed to actually point out a tangible benefit which is achieved by\n> > breaking compatibility like this.\n> \n> Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty \n> much day#1. The number of people complaining about it going away has \n> literally been _much_ smaller than the people who complained about it \n> being there.\n> \n> Also, like it or not, it's done. So the argument about \"compatibility\" is \n> TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already \n> released a major version without them.\n\nWell, you can still install git-* to /usr/bin by specifying\ngitexecdir=/usr/bin at make. So, the compatibility is not lost.\n\nIt's just a default configuration issue, IMO.\n\n\nTakashi\n"},{"id":"88610","messageId":"20080826173512.GS10544@machine.or.cz","threadId":"15184","inReplyTo":"80myizelcw.fsf@tiny.isode.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-26T17:35:12Z","receivedAt":"2008-08-26T17:35:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 26, 2008 at 06:29:03PM +0100, Bruce Stephens wrote:\n> - it means git on Windows has the same interface\n> \n> (Arguably the latter point ought to be \"forces Unix users to use the\n> same interface as on Windows\", but the git-foo forms have been\n> deprecated on all platforms for a while. Making Unix and Windows the\n> same seems a worthwhile goal, though presumably it's irrelevant for\n> linux kernel people.)\n\nI actually checked, and my msysgit installation does hardlinking (or at\nleast pretends to do, and ls -l shows high linkcounts). And somewhat\namusingly, it doesn't appear that 1.6.0 will be released for Windows\nanytime soon, though that's of course not relevant from long term\nperspective.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"88612","messageId":"80fxorekxs.fsf@tiny.isode.net","threadId":"15184","inReplyTo":"20080826173512.GS10544@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Bruce Stephens","fromEmail":"bruce.stephens@isode.com","sentAt":"2008-08-26T17:38:07Z","receivedAt":"2008-08-26T17:38:07Z","isPatch":false,"sender":{"key":"bruce.stephens@isode.com","avatar":null},"body":"Petr Baudis writes:\n\n[...]\n\n> I actually checked, and my msysgit installation does hardlinking (or at\n> least pretends to do, and ls -l shows high linkcounts). And somewhat\n> amusingly, it doesn't appear that 1.6.0 will be released for Windows\n> anytime soon, though that's of course not relevant from long term\n> perspective.\n\nIIRC git.exe knows how to run Tcl scripts (maybe perl and\nshell-scripts), and on Windows you need to use \"git gui\" and things\nbecause \"git-gui\" won't work.\n"},{"id":"88613","messageId":"m3y72jr80w.fsf@localhost.localdomain","threadId":"15184","inReplyTo":"20080826171144.21328.82727.stgit@localhost","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-26T17:38:45Z","receivedAt":"2008-08-26T17:38:45Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis writes:\n\n> git still shows way too many commands, some of them\n> are clearly plumbing. This patch hides the plumbing commands\n> liberally (that is, in special cases, users still might want to\n> call one of the hidden commands, a *normal* workflow should never\n> involve these, though - and if it does, we have a UI problem anyway).\n> \n> Signed-off-by: Petr Baudis \n> ---\n> \n> contrib/completion/git-completion.bash | 10 ++++++++++\n> 1 files changed, 10 insertions(+), 0 deletions(-)\n> \n> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\n> index 89858c2..773d64b 100755\n> --- a/contrib/completion/git-completion.bash\n> +++ b/contrib/completion/git-completion.bash\n> @@ -386,7 +386,9 @@ __git_porcelain_commands ()\n> \t\tcat-file) : plumbing;;\n> \t\tcheck-attr) : plumbing;;\n> \t\tcheck-ref-format) : plumbing;;\n> +\t\tcheckout-index) : plumbing;;\n\nClearly plumbing.\n\n> \t\tcommit-tree) : plumbing;;\n> +\t\tcount-objects) : plumbing;;\n\nPlumbing (hyphenated name is a very good hint), but useful to decide\nwhen to repack. I'm partially to leaving it, as I use it from time to\ntime from CLI.\n\n> \t\tcvsexportcommit) : export;;\n> \t\tcvsimport) : import;;\n> \t\tcvsserver) : daemon;;\n> @@ -395,6 +397,7 @@ __git_porcelain_commands ()\n> \t\tdiff-index) : plumbing;;\n> \t\tdiff-tree) : plumbing;;\n> \t\tfast-import) : import;;\n> +\t\tfast-export) : export;;\n\nGood catch. BTW. both fast-import and fast-export are plumbing, in a\nsense that I don't see how they can be used from command line\n(well...)\n\n> \t\tfsck-objects) : plumbing;;\n> \t\tfetch-pack) : plumbing;;\n> \t\tfmt-merge-msg) : plumbing;;\n> @@ -404,6 +407,10 @@ __git_porcelain_commands ()\n> \t\tindex-pack) : plumbing;;\n> \t\tinit-db) : deprecated;;\n> \t\tlocal-fetch) : plumbing;;\n> +\t\tlost-found) : deprecated;;\n\nTrue.\n\n> +\t\tls-files) : plumbing;;\n\nIIRC it doesn't have porcelain equivalent.\n\n> +\t\tls-remote) : plumbing;;\n\n\"git remote show\" is porcelain equivalent.\n\n> +\t\tls-tree) : plumbing;;\n\n\"git show\" can be used instead.\n\n> \t\tmailinfo) : plumbing;;\n> \t\tmailsplit) : plumbing;;\n> \t\tmerge-*) : plumbing;;\n> @@ -428,6 +435,7 @@ __git_porcelain_commands ()\n> \t\trunstatus) : plumbing;;\n> \t\tsh-setup) : internal;;\n> \t\tshell) : daemon;;\n> +\t\tshow-ref) : plumbing;;\n\nClearly plumbing.\n\n> \t\tsend-pack) : plumbing;;\n> \t\tshow-index) : plumbing;;\n> \t\tssh-*) : transport;;\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"88617","messageId":"20080826174254.GA8441@mithlond.arda.local","threadId":"15184","inReplyTo":"20080826170748.GB5318@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-08-26T17:42:54Z","receivedAt":"2008-08-26T17:42:54Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Jeff King wrote (2008-08-26 13:07 -0400):\n\n> On Tue, Aug 26, 2008 at 06:25:13PM +0200, Petr Baudis wrote:\n> \n> > > git- ... what? 140-something commands? I'll better start\n> > > looking for alternatives _right now_!\n> > \n> > Actually, this is the only realistic argument I can remember at all.\n> > Are there any others? I couldn't come up with any - but I didn't do\n> > much history digging: others seem to be equally in dark, though.\n> \n> The three reasons I can recall are:\n\nDon't know about \"original\" reasons but filling users' ~/bin isn't nice \neither. I always install all of the self-built git under $HOME. Since \n\"make install\" (by default) used to fill ~/bin with those 140 git-* \nexecutables I already configured git to install itself to a custom \ndirectory. I had to use $GIT_EXEC_PATH and create some symlinks but with \n1.6.0 I don't have to do this anymore. Me happy.\n\nSetting $GIT_EXEC_PATH wasn't a big deal and I can't see it being a big \ndeal now, for some other people, to extend their $PATH to include every \nimaginable git-* executable in the system.\n\nBTW I'd also vote for reducing the number of commands printed with \"git \n\" bash-completion.\n"},{"id":"88615","messageId":"m3tzd7r7tr.fsf@localhost.localdomain","threadId":"15184","inReplyTo":"20080826172410.GJ26523@spearce.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-26T17:43:02Z","receivedAt":"2008-08-26T17:43:02Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Petr Baudis wrote:\n> > git still shows way too many commands, some of them\n> > are clearly plumbing. This patch hides the plumbing commands\n> > liberally (that is, in special cases, users still might want to\n> > call one of the hidden commands, a *normal* workflow should never\n> > involve these, though - and if it does, we have a UI problem anyway).\n> > \n> > Signed-off-by: Petr Baudis \n> \n> Acked-by: Shawn O. Pearce \n> \n> Though I use git ls-remote at least once every other day to see\n> what branches are available on my egit/spearce.git fork. Its ok,\n> I guess I can type a few extra characters...\n\nOne would think that one can use \"git remote show \" instead of\n\"git ls-remote \", but I'm not sure if it does show also\n_untracked_ remote branches.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"88618","messageId":"fcaeb9bf0808261047h3a37c90ds5b41bccd6e0512d7@mail.gmail.com","threadId":"15184","inReplyTo":"20080826171623.GE5318@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-08-26T17:47:15Z","receivedAt":"2008-08-26T17:47:15Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On 8/27/08, Jeff King wrote:\n> On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:\n>\n> > I'm the reason why count-objects, ls-tree and checkout-index are\n> > still offered by the bash completion. And sitting here reading your\n> > email I realized its been _months_ since I last called checkout-index\n> > by hand. I still run count-objects and ls-tree very so often, but the\n> > average user probably doesn't use ls-tree.\n> >\n> > So yea, these probably should be removed from the completion list.\n> > But I can make a weak argument for keeping count-objects.\n>\n>\n> I think this message shows the conflict in setting up such a list. We\n> want the command set to be as tiny as possible to help new users find\n> their way. But we want the command set to be useful to git power users.\n>\n> I wonder if there should be multiple sets of commands for completion,\n> with a minimal set enabled by default, and a \"power user\" set that\n> exposes extra commands. I dunno. Maybe that is overengineering. I don't\n> even use the bash completion at all.\n\nHow about providing a standard set of aliases? All other SCMs I know\ndo it. You can type it short/quick without depending on bash.\n-- \nDuy\n"},{"id":"88623","messageId":"20080826180926.GA25711@isilmar.linta.de","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808260959000.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Dominik Brodowski","fromEmail":"linux@dominikbrodowski.net","sentAt":"2008-08-26T18:09:26Z","receivedAt":"2008-08-26T18:09:26Z","isPatch":false,"sender":{"key":"linux@dominikbrodowski.net","avatar":null},"body":"Linus,\n\nOn Tue, Aug 26, 2008 at 10:03:25AM -0700, Linus Torvalds wrote:\n> > Nice emotive response, especially the subtle but unsubstantiated 'silent\n> > majority in favour' bit -- but you forgot the part where you were\n> > supposed to actually point out a tangible benefit which is achieved by\n> > breaking compatibility like this.\n> \n> Umm. The 'git-xyzzy' thing has been one of the #1 complaints since pretty \n> much day#1.\n\nBut _why_ do they complain? Just whining or real reasons?\n\n> Also, like it or not, it's done. So the argument about \"compatibility\" is \n> TOTAL AND UTTER BULLSHIT. There is no compatibility, because we already \n> released a major version without them.\n\nThen release a 1.6.0.1. But the major problem is something else: it's that\ndoing PATH=\"$PATH:$(git --exec-path) is also deprecated, i.e. that workaround\nis to go away in one of the next releases too.\n\n> - new people don't even learn the mistakes\n\nBut new people read \"git-diff-tree\" in the man pages, and then wonder why\n\"git-diff-tree\" does not work. People read howtos in the Documentation/\ndirectory and wonder why executing \"git-diff-tree\" does not work. Besides,\nwhy it is a \"mistake\" to use git-xyzyy? Also, note that 1.5.4.x man pages\nuses git-xyzzy form in many many places, not hinting at all of git-xyzyy\nbeing deprecated.\n\n> and there really is zero downside apart from the _trivial_ downside of you \n> just having to add a single PATH thing to your .bashrc or something.\n\ndownsides:\n\n- man pages. man git-add for the command \"git add\" is a bit...\n disappointing.\n\n- lots of documentation using \"git-xyzyy\"\n\n- the PATH workaround being deprecated\n\nBest,\n\tDominik\n"},{"id":"88625","messageId":"alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"20080826180926.GA25711@isilmar.linta.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-26T18:19:28Z","receivedAt":"2008-08-26T18:19:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Aug 2008, Dominik Brodowski wrote:\n> \n> But _why_ do they complain? Just whining or real reasons?\n\nWell, considering that I think the people who complain about the 1.6.0 \nbehaviour are whining, what does it matter?\n\nPeople always think their own concerns are so incredibly important. \n\nI always thought that git-xyzzy was fine. After all, I _did_ it that way \nto begin with. But people complained, and the whole alias thing meant that \nit couldn't be the primary interface _anyway_, so I changed my opinion.\n\nI don't actually personally feel all that strongly, but I _do_ think that \nright now the git-xyzzy proponents are whining. All of their arguments are \npure and utter CRAP, considering the triviality of\n\n\tPATH=\"$PATH:$(git --exec-path)\"\n\nReally. I repeat that mantra over and over, exactly because it makes all \nthe whining so _pointless_.\n\nWhy do people still whine about this? Really? None of the whiners have \nanswered that simple PATH mantra, BECAUSE THEY CANNOT.\n\nSo when you ask \"why do they complain\", look at both sides. Both sides \ncomplain about totally stupid things.\n\nbut the FACT is that git-1.6.0 can work either way. So the people who \ncomplain about having lost git-xyzzy are the ones that are being stupid. \n\nAt least the ones who complained about \"git-\" being scary had a \n_point_.\n\n> Then release a 1.6.0.1. But the major problem is something else: it's that\n> doing PATH=\"$PATH:$(git --exec-path) is also deprecated, i.e. that workaround\n> is to go away in one of the next releases too.\n\nNO, IT IS NOT DEPRECATED.\n\nThat was a plan. I think that plan got scuttled already. Stop whining!\n\nCan't you understand that people can change plans based on feedback?\n\nEffing whiners. \n\n\t\tLinus\n"},{"id":"88626","messageId":"7v1w0bab1c.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080826172410.GJ26523@spearce.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-26T18:25:35Z","receivedAt":"2008-08-26T18:25:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Petr Baudis wrote:\n>> git still shows way too many commands, some of them\n>> are clearly plumbing. This patch hides the plumbing commands\n>> liberally (that is, in special cases, users still might want to\n>> call one of the hidden commands, a *normal* workflow should never\n>> involve these, though - and if it does, we have a UI problem anyway).\n>> \n>> Signed-off-by: Petr Baudis \n>\n> Acked-by: Shawn O. Pearce \n>\n> Though I use git ls-remote at least once every other day to see\n> what branches are available on my egit/spearce.git fork. Its ok,\n> I guess I can type a few extra characters...\n\nRevision-requested-by: me\n\nUnless/until we have an easy way to obtain the information \"git-ls-files\n-u\" gives during conflict resolution, ls-files should stay on the list of\ncommonly used commands.\n"},{"id":"88627","messageId":"20080826182736.GL26523@spearce.org","threadId":"15184","inReplyTo":"7v1w0bab1c.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-26T18:27:36Z","receivedAt":"2008-08-26T18:27:36Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Petr Baudis wrote:\n> >> git still shows way too many commands, some of them\n> >> are clearly plumbing. This patch hides the plumbing commands\n> >> liberally (that is, in special cases, users still might want to\n> >> call one of the hidden commands, a *normal* workflow should never\n> >> involve these, though - and if it does, we have a UI problem anyway).\n> >> \n> >> Signed-off-by: Petr Baudis \n> >\n> > Acked-by: Shawn O. Pearce \n> >\n> > Though I use git ls-remote at least once every other day to see\n> > what branches are available on my egit/spearce.git fork. Its ok,\n> > I guess I can type a few extra characters...\n> \n> Revision-requested-by: me\n> \n> Unless/until we have an easy way to obtain the information \"git-ls-files\n> -u\" gives during conflict resolution, ls-files should stay on the list of\n> commonly used commands.\n\nPerhaps users should just do:\n\n git config --global alias.unmerged 'ls-files -u'\n\n?\n\nOk, well, maybe git.c should do that for you as a builtin.\n\n-- \nShawn.\n"},{"id":"88630","messageId":"20080826185548.GA7559@hera.kernel.org","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Al Viro","fromEmail":"viro@hera.kernel.org","sentAt":"2008-08-26T18:55:48Z","receivedAt":"2008-08-26T18:55:48Z","isPatch":false,"sender":{"key":"viro@hera.kernel.org","avatar":null},"body":"On Tue, Aug 26, 2008 at 11:19:28AM -0700, Linus Torvalds wrote:\n> but the FACT is that git-1.6.0 can work either way. So the people who \n> complain about having lost git-xyzzy are the ones that are being stupid. \n> \n> At least the ones who complained about \"git-\" being scary had a \n> _point_.\n\nWell, to be fair, \"man git-add for git add is rather unconventional\" is\na valid point...\n\nFWIW, personally I couldn't care less as long as manpages *are* there and\nwe do not end up with something like \"oh, just use info / html / some other\nweird crap; manpages are not suitable(tm), dontcha know\"\n"},{"id":"88631","messageId":"alpine.LNX.1.00.0808261455010.19665@iabervon.org","threadId":"15184","inReplyTo":"7v1w0bab1c.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-08-26T19:04:12Z","receivedAt":"2008-08-26T19:04:12Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 26 Aug 2008, Junio C Hamano wrote:\n\n> \"Shawn O. Pearce\" writes:\n> \n> > Petr Baudis wrote:\n> >> git still shows way too many commands, some of them\n> >> are clearly plumbing. This patch hides the plumbing commands\n> >> liberally (that is, in special cases, users still might want to\n> >> call one of the hidden commands, a *normal* workflow should never\n> >> involve these, though - and if it does, we have a UI problem anyway).\n> >> \n> >> Signed-off-by: Petr Baudis \n> >\n> > Acked-by: Shawn O. Pearce \n> >\n> > Though I use git ls-remote at least once every other day to see\n> > what branches are available on my egit/spearce.git fork. Its ok,\n> > I guess I can type a few extra characters...\n> \n> Revision-requested-by: me\n> \n> Unless/until we have an easy way to obtain the information \"git-ls-files\n> -u\" gives during conflict resolution, ls-files should stay on the list of\n> commonly used commands.\n\nDoesn't \"git status\" tell you that? Or do you want the extra info from the \nimplicit --stage?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"88632","messageId":"alpine.LFD.1.10.0808261202280.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"20080826185548.GA7559@hera.kernel.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-26T19:04:51Z","receivedAt":"2008-08-26T19:04:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Aug 2008, Al Viro wrote:\n> \n> Well, to be fair, \"man git-add for git add is rather unconventional\" is\n> a valid point...\n\nOn the other hand:\n\n - \"man\" simply cannot currently handle \"man git add\", even though there's \n been some noise to teach it.\n\n - you can use \"git help add\" instead, since git itself does understand \n this. It will just go \"man git-add\" for you, so that your fingers don't \n have to type that dash ;)\n\n> FWIW, personally I couldn't care less as long as manpages *are* there and\n> we do not end up with something like \"oh, just use info / html / some other\n> weird crap; manpages are not suitable(tm), dontcha know\"\n\nI don't think _that_ is going to happen. You're not the only one who wants \nman-pages.\n\n\t\tLinus\n"},{"id":"88633","messageId":"20080826190752.GM26523@spearce.org","threadId":"15184","inReplyTo":"alpine.LNX.1.00.0808261455010.19665@iabervon.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-08-26T19:07:52Z","receivedAt":"2008-08-26T19:07:52Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Daniel Barkalow wrote:\n> On Tue, 26 Aug 2008, Junio C Hamano wrote:\n> > \n> > Unless/until we have an easy way to obtain the information \"git-ls-files\n> > -u\" gives during conflict resolution, ls-files should stay on the list of\n> > commonly used commands.\n> \n> Doesn't \"git status\" tell you that? Or do you want the extra info from the \n> implicit --stage?\n\nI think he doesn't want to see the other files that are already\nmerged successfully. git status shows them, git ls-files -u\ndoes not.\n\n-- \nShawn.\n"},{"id":"88634","messageId":"20080826191140.GA19785@mithlond.arda.local","threadId":"15184","inReplyTo":"20080826185548.GA7559@hera.kernel.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-08-26T19:11:40Z","receivedAt":"2008-08-26T19:11:40Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Al Viro wrote (2008-08-26 18:55 +0000):\n\n> Well, to be fair, \"man git-add for git add is rather unconventional\" is\n> a valid point...\n\nTrue. I'd say that for people familiar with other VCS/SCM tools the \n\"$VCS help add\" is probably the primary help interface. It works with \nmany tools - git, hg, svn and bzr at least.\n"},{"id":"88636","messageId":"20080826192255.GA16066@hera.kernel.org","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261202280.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Al Viro","fromEmail":"viro@hera.kernel.org","sentAt":"2008-08-26T19:22:55Z","receivedAt":"2008-08-26T19:22:55Z","isPatch":false,"sender":{"key":"viro@hera.kernel.org","avatar":null},"body":"On Tue, Aug 26, 2008 at 12:04:51PM -0700, Linus Torvalds wrote:\n> \n> \n> On Tue, 26 Aug 2008, Al Viro wrote:\n> > \n> > Well, to be fair, \"man git-add for git add is rather unconventional\" is\n> > a valid point...\n> \n> On the other hand:\n> \n> - \"man\" simply cannot currently handle \"man git add\", even though there's \n> been some noise to teach it.\n> \n> - you can use \"git help add\" instead, since git itself does understand \n> this. It will just go \"man git-add\" for you, so that your fingers don't \n> have to type that dash ;)\n\nYeah... Actually, it all boils down to YAsrbBogosity. Namely, rather\ndumb conventions for $PATH; it would be much saner if the things worked\nas for $CDPATH. That is,\n/ -> use that as-is\n./ -> use that as-is\n../ -> use that as-is\n -> try to use / for each\npath element.\n\nThe difference, of course, is that things like git/subcommand would end up\nas /usr/bin/git/subcommand, nicely gathering related stuff together in\nobvious place and keeping the size of /usr/bin down. Without the holy\nwars about irregular syntax, etc., etc.\n\nNot that it had been the worst offense against the sanity and taste that\nwent into sh(1)...\n"},{"id":"88635","messageId":"alpine.LNX.1.00.0808261517200.19665@iabervon.org","threadId":"15184","inReplyTo":"20080826190752.GM26523@spearce.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-08-26T19:23:53Z","receivedAt":"2008-08-26T19:23:53Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 26 Aug 2008, Shawn O. Pearce wrote:\n\n> Daniel Barkalow wrote:\n> > On Tue, 26 Aug 2008, Junio C Hamano wrote:\n> > > \n> > > Unless/until we have an easy way to obtain the information \"git-ls-files\n> > > -u\" gives during conflict resolution, ls-files should stay on the list of\n> > > commonly used commands.\n> > \n> > Doesn't \"git status\" tell you that? Or do you want the extra info from the \n> > implicit --stage?\n> \n> I think he doesn't want to see the other files that are already\n> merged successfully. git status shows them, git ls-files -u\n> does not.\n\nI think it might make sense to support \"git status --unmerged\" or \nsomething like that, where it filters the output by the tags it would \nshow.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"88644","messageId":"48B46443.6000800@kernel.org","threadId":"15184","inReplyTo":"20080826182349.0a1a75e2@hyperion.delvare","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"H. Peter Anvin","fromEmail":"hpa@kernel.org","sentAt":"2008-08-26T20:14:59Z","receivedAt":"2008-08-26T20:14:59Z","isPatch":false,"sender":{"key":"hpa@kernel.org","avatar":null},"body":"Jean Delvare wrote:\n> \n> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but\n> to the silent majority I am a proud member of, it was. (I'm not saying\n> that the path that was taken to get there was optimal, just that the\n> goal was sound.)\n> \n\nYou keep trying to use the Nixon argument (\"silent majority.\") You *do* \nknow that it was a rhetorical device used by Nixon's speechwriters to \npush ahead with policies despite compact opposition, don't you?\n\nAs far as I can tell, most of the arguments in favour came from fanbois \nof $OTHER_SCM which went along the lines of \"why does git need all this \nstuff in /usr/bin, when $OTHER_SCM doesn't?\" It had nothing to do with \nreality, of course; it was just a difference between git and $OTHER_SCM \nwhich they choose to pick on.\n\n\t-hpa\n"},{"id":"88645","messageId":"7vr68b8q9p.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080826145719.GB5046@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-26T20:39:30Z","receivedAt":"2008-08-26T20:39:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Aug 25, 2008 at 04:41:57PM -0700, Junio C Hamano wrote:\n>\n>> > Umm. What exactly makes you feel you should ignore the discussions we had \n>> > around the issues on the git and msysgit mailing list?\n>> \n>> Well, this was partly my fault, as I did not make it clear in this part\n>> that beating the horse that has been dead for two years is not a\n>> productive way to spend out time. I however did, in the part David did\n>> not quote, try to make it clear:\n>> \n>> That's all history now anyway. We should try to do better the next time,\n>> which is much more important, and that is the topic of this message.\n>\n> I don't want to stir up this discussion too much; I am sure you have\n> many more important things to be working on. But I did want to make one\n> observation.\n>\n> One side of the argument, I see a lot of \"I would prefer it this way.\"\n> And on the other side I see a lot of \"this discussion is already\n> history\" and \"but I do not care personally that much.\"\n>\n> It makes me wonder why nobody has said \"no, really, I prefer it without\n> the programs in /bin.\" Are they simply confident that the decision has\n> been made, and don't feel the need to say something?\n\nTo me, one of the two saddest part of this story is this.\n\nI was among the \"don't change anything, get used to it just like old\ntimers are already used to\" camp, when people said that having many\ncommands in /usr/bin (or $HOME/bin) would scare people and pushed for this\nchange, around the end of 2005 through early 2006. The pros-and-cons\nwasn't clearly cut-and-dried. Moving out of /usr/bin has slight technical\nmerits (e.g. \"bash completion not showing 150+ commands but only selected\nPorcelains\", \"not scaring people off\", \"dashless form is needed if you\nwant to use global options\", and \"moving away from dashed form will\neventually let us get rid of copies on systems without hardlinks even from\nunder /usr/libexec/git-core\"). But I do not think the advantage was so\ngreat.\n\nWhen I hear something like what David Woodhouse said in this thread, I\nshould be feeling \"People -- those of you who claimed to be the silent\nmajority -- see, I told you so! This is a very bad move\".\n\nBut I can't. People who complain _now_ just annoy me even more. Why\nweren't you defending the backward compatibility with me, which you seem\nto value it so much, perhaps even more than I did back then? Why are you\nwasting our time bringing it up again, instead of joining the discussion\nwhen it _mattered_ back then?\n\nAnd I still think there is no great reason to pick one way or the other.\nHaving everything in /usr/bin does not have any better reason than \"it has\nbeen that way from the beginning\", and that certainly is not a reason\nstrong enough to revert this anymore, as the opposition now has \"the\nlatest and greatest was shipped with the new layout\" which is an equally\nvalid argument.\n\nAnother, even more sad part of this story is that the thread was confused\ninto talking about the change that has already happened, which is a total\nofftopic, and wasted even more time from people.\n\nRead the subject line again, and notice that we are not talking about\n/usr/bin vs /usr/libexec/git-core; the request-for-discussion was about\nremoving \"git-add\" and friends from /usr/libexec/git-core/, so that we do\nnot have to even have these many hardlinks there. Except for Linus (and\nobviously myself who started the thread), I saw nobody expressed any\nopinion on it.\n"},{"id":"88651","messageId":"alpine.DEB.1.10.0808261658120.17093@gandalf.stny.rr.com","threadId":"15184","inReplyTo":"48B3EF6B.7070400@s5r6.in-berlin.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2008-08-26T21:00:04Z","receivedAt":"2008-08-26T21:00:04Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"\nOn Tue, 26 Aug 2008, Stefan Richter wrote:\n\n> A Large Angry SCM wrote:\n> > Jean Delvare wrote:\n> >> On Mon, 25 Aug 2008 22:58:37 -0400, A Large Angry SCM wrote:\n> >>> David Woodhouse wrote:\n> >>>> (C) Just don't do it. Leave the git-foo commands as they were. They\n> >>>> weren't actually hurting anyone, and you don't actually _gain_\n> >>>> anything by removing them. For those occasional nutters who\n> >>>> _really_ care about the size of /usr/bin, give them the _option_\n> >>>> of a 'make install' without installing the aliases.\n> >>> Acked-by: A Large Angry SCM \n> [...]\n> > Do some research; [...]\n> \n> ...the plan to move git-foo out of /usr/bin has been discussed and \n> wrapped up quite a while ago (am I confident to say without being \n> subscriber of git@vger.k'org myself).\n> \n\nI'm sorry, but this thread reminds me of the day Aurther Dent's house was \ngoing to be destroyed for a by-way. ;-)\n\n-- Steve\n"},{"id":"88653","messageId":"20080826210318.GA6305@coredump.intra.peff.net","threadId":"15184","inReplyTo":"7vr68b8q9p.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-26T21:03:19Z","receivedAt":"2008-08-26T21:03:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:\n\n> But I can't. People who complain _now_ just annoy me even more. Why\n> weren't you defending the backward compatibility with me, which you seem\n> to value it so much, perhaps even more than I did back then? Why are you\n> wasting our time bringing it up again, instead of joining the discussion\n> when it _mattered_ back then?\n\nYes, I was hoping my message would help provoke them to say \"here is why\nI did not do it back then, and why this should be revisited now\". But\nall it seems to have done is bring up more arguments that should have\nbeen given back then. So for that I apologize, since I know that is\nexactly what you did not want to read. ;)\n\n> Read the subject line again, and notice that we are not talking about\n> /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about\n> removing \"git-add\" and friends from /usr/libexec/git-core/, so that we do\n> not have to even have these many hardlinks there. Except for Linus (and\n> obviously myself who started the thread), I saw nobody expressed any\n> opinion on it.\n\nI was slightly negative on the change at the time of \"/usr/bin vs\n/usr/libexec/git-core\" and I planned to put \"git --exec-path\" in my\nPATH. But I gave the new way a try, and I have not been very bothered.\nSo let me say that I really don't care much what happens with libexec,\nand you can hold me to that when the next flame-war breaks out if such a\nchange is implemented. Now you have three opinions. :)\n\nI really was just concerned that we are rejecting legitimate, popular\nconcerns because of a grumpy \"you missed the deadline\" stance, when\nperhaps there is a good reason (which I am still waiting to hear) that\nthose concerns missed the deadline.\n\n-Peff\n"},{"id":"88654","messageId":"20080826210631.GC3812@1wt.eu","threadId":"15184","inReplyTo":"20080826171623.GE5318@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Willy Tarreau","fromEmail":"w@1wt.eu","sentAt":"2008-08-26T21:06:31Z","receivedAt":"2008-08-26T21:06:31Z","isPatch":false,"sender":{"key":"w@1wt.eu","avatar":"https://avatars.githubusercontent.com/u/8141789?v=4"},"body":"On Tue, Aug 26, 2008 at 01:16:24PM -0400, Jeff King wrote:\n> On Tue, Aug 26, 2008 at 10:12:55AM -0700, Shawn O. Pearce wrote:\n> \n> > I'm the reason why count-objects, ls-tree and checkout-index are\n> > still offered by the bash completion. And sitting here reading your\n> > email I realized its been _months_ since I last called checkout-index\n> > by hand. I still run count-objects and ls-tree very so often, but the\n> > average user probably doesn't use ls-tree.\n> > \n> > So yea, these probably should be removed from the completion list.\n> > But I can make a weak argument for keeping count-objects.\n> \n> I think this message shows the conflict in setting up such a list. We\n> want the command set to be as tiny as possible to help new users find\n> their way. But we want the command set to be useful to git power users.\n> \n> I wonder if there should be multiple sets of commands for completion,\n> with a minimal set enabled by default, and a \"power user\" set that\n> exposes extra commands. I dunno. Maybe that is overengineering. I don't\n> even use the bash completion at all.\n\nThe problem is not caused by the number of commands, but by their\ncomplexity. I need completion because it's hard to type their very\nlong names without making mistakes (not counting the long options).\n\"git am\" is fine with me, but \"git format-patch\" is quite boring to\ntype. It's also interesting to note that short names are currently\nin place for less commonly used commands : git-rm, git-mv, git-gc.\n\nWilly\n"},{"id":"88655","messageId":"20080826210857.GA29208@isilmar.linta.de","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Dominik Brodowski","fromEmail":"linux@dominikbrodowski.net","sentAt":"2008-08-26T21:08:57Z","receivedAt":"2008-08-26T21:08:57Z","isPatch":false,"sender":{"key":"linux@dominikbrodowski.net","avatar":null},"body":"Linus,\n\nOn Tue, Aug 26, 2008 at 11:19:28AM -0700, Linus Torvalds wrote:\n> \tPATH=\"$PATH:$(git --exec-path)\"\n> \n> Really. I repeat that mantra over and over, exactly because it makes all \n> the whining so _pointless_.\n\nIt does indeed make it pointless, as long this PATH thing is staying.\nHowever, some of the arguments (finally!) mentioned in this thread make me\nworrying otherwise, for they become moot if this PATH thing stays. Also,\n\n> NO, IT IS NOT DEPRECATED.\n\nthis is the first time -- despite repeated questions -- that the deprecation\nnotice got deprecated.\n\n> Can't you understand that people can change plans based on feedback?\n\nIndeed I can understand it. If people tell about it.\n\nBest,\n\tDominik\n"},{"id":"88656","messageId":"7vk5e38o0d.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-26T21:28:18Z","receivedAt":"2008-08-26T21:28:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n>> ... But the major problem is something else: it's that\n>> doing PATH=\"$PATH:$(git --exec-path) is also deprecated, i.e. that workaround\n>> is to go away in one of the next releases too.\n>\n> NO, IT IS NOT DEPRECATED.\n>\n> That was a plan. I think that plan got scuttled already. Stop whining!\n>\n> Can't you understand that people can change plans based on feedback?\n>\n> Effing whiners. \n\nI do not think \"the plan got scuttled *already*\" before you said so. It\nwas the purpose for this thread to discuss it.\n\nYou effectively vetoed the plan with your statement just now, and that\nsettles it. We can now officially declare the plan got scuttled and we\ncan all go back to our happy lives ;-).\n\nThanks.\n"},{"id":"88657","messageId":"alpine.LFD.1.10.0808261435470.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"7vk5e38o0d.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-26T21:38:11Z","receivedAt":"2008-08-26T21:38:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 26 Aug 2008, Junio C Hamano wrote:\n> \n> I do not think \"the plan got scuttled *already*\" before you said so. It\n> was the purpose for this thread to discuss it.\n>\n> You effectively vetoed the plan with your statement just now, and that \n> settles it.\n\nI wouldn't say I vetoed i, but wasn't it pretty obvious from the whole \ndiscussion that a fair number of people want to keep git-xyzzy?\n\nSo getting rid of git-xyzzy altogether would seem to be stupid, and not \nlistening to users.\n\nSo I'm not \"vetoing\" it, but I don't think git maintainers (past _or_ \ncurrent ;) have been stupid, or unable to listen to people, and as such I \nthink the end result is pretty obvious.\n\n\t\t\tLinus\n"},{"id":"88658","messageId":"vpqiqtnsasb.fsf@bauges.imag.fr","threadId":"15184","inReplyTo":"20080826171144.21328.82727.stgit@localhost","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-08-26T21:53:40Z","receivedAt":"2008-08-26T21:53:40Z","isPatch":true,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Petr Baudis writes:\n\n> git still shows way too many commands, some of them\n> are clearly plumbing. This patch hides the plumbing commands\n> liberally (that is, in special cases, users still might want to\n> call one of the hidden commands, a *normal* workflow should never\n> involve these, though - and if it does, we have a UI problem anyway).\n\nIs it possible to have the completion not show them by default, but\nfall back to them if no other completion is found?\n\n-- \nMatthieu\n"},{"id":"88668","messageId":"23DFA9EC-9523-4179-BA3C-ACBDB82953DF@cs.indiana.edu","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261114070.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-26T23:21:41Z","receivedAt":"2008-08-26T23:21:41Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 26, 2008, at 11:19 AM, Linus Torvalds wrote:\n> I don't actually personally feel all that strongly, but I _do_ think \n> that\n> right now the git-xyzzy proponents are whining. All of their \n> arguments are\n> pure and utter CRAP, considering the triviality of\n>\n> \tPATH=\"$PATH:$(git --exec-path)\"\n\nScripts. Remote scripts. Scripts running as arbitrary users.\n\nI'm trying to upgrade the git that our scripts use, and having the \nusers modify their paths doesn't work.\n\nNot that horrible to fix some other way, but still a rude thing to \nwake up to one day. (ie, today)\n\n-- Perry Wagle (wagle@mac.com)\n"},{"id":"88666","messageId":"DD3976FB-09E7-4E78-BB4E-7E61AF827C95@cs.indiana.edu","threadId":"15184","inReplyTo":"7vr68b8q9p.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-26T23:36:33Z","receivedAt":"2008-08-26T23:36:33Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"On Aug 26, 2008, at 1:39 PM, Junio C Hamano wrote:\n\n> But I can't. People who complain _now_ just annoy me even more. Why\n> weren't you defending the backward compatibility with me, which you \n> seem\n> to value it so much, perhaps even more than I did back then? Why \n> are you\n> wasting our time bringing it up again, instead of joining the \n> discussion\n> when it _mattered_ back then?\n\nI wasn't around back then. I came in a year ago to write some git \nscripts (mostly for hooks). I saw that lots of scripts (including \ngitweb and the sample hooks) used the git- form, and some didn't. I \nfound that I liked the git- form, since it permitted command and man \npage name completion, so I did that.\n\nToday I literally wake up to find that I now gotta go fix all those \nscripts, upgrade git-web, and whatever other *scripts* used the now \nobsolete git- form. Sorry, I skim the git list every week or three.\n\nThe doctor says I'll live, and be back to health in a few hours. But \nthere will be a doctor bill. Can I send it to you? 8)\n\n-- Perry Wagle (wagle@mac.com)\n"},{"id":"88667","messageId":"alpine.LFD.1.10.0808261717480.1624@xanadu.home","threadId":"15184","inReplyTo":"7vr68b8q9p.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-08-26T23:45:41Z","receivedAt":"2008-08-26T23:45:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 26 Aug 2008, Junio C Hamano wrote:\n\n> Read the subject line again, and notice that we are not talking about\n> /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about\n> removing \"git-add\" and friends from /usr/libexec/git-core/, so that we do\n> not have to even have these many hardlinks there. Except for Linus (and\n> obviously myself who started the thread), I saw nobody expressed any\n> opinion on it.\n\nDon't deprecate git-foo and leave them in $gitexecdir as things are now.\nThat's the best compromise IMHO.\n\nThose who want git-foo can have it via several and easy means. Those \nwho want 'git foo' have it by default which IMHO is pretty sane (the \nother way around is less easy so 'git foo' being the default is the most \nsensible alternative).\n\nPlatforms where filesystem links are not available simply don't have to \nsupport the git-foo form, period. I doubt users of such platforms will \ncare much.\n\nAll the rest is only bikeshedding.\n\n\nNicolas\n"},{"id":"88670","messageId":"20080827001705.GG23698@parisc-linux.org","threadId":"15184","inReplyTo":"7vr68b8q9p.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthew Wilcox","fromEmail":"matthew@wil.cx","sentAt":"2008-08-27T00:17:05Z","receivedAt":"2008-08-27T00:17:05Z","isPatch":false,"sender":{"key":"matthew@wil.cx","avatar":null},"body":"On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:\n> When I hear something like what David Woodhouse said in this thread, I\n> should be feeling \"People -- those of you who claimed to be the silent\n> majority -- see, I told you so! This is a very bad move\".\n> \n> But I can't. People who complain _now_ just annoy me even more. Why\n> weren't you defending the backward compatibility with me, which you seem\n> to value it so much, perhaps even more than I did back then? Why are you\n> wasting our time bringing it up again, instead of joining the discussion\n> when it _mattered_ back then?\n\nWe didn't know the conversation was going on. Why should we? We only\nuse the tool, not develop it. I'm also not on the mailing lists for\nmutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\nany of the dozens of other programs I use on a daily basis.\n\n-- \nMatthew Wilcox\t\t\t\tIntel Open Source Technology Centre\n\"Bill, look, we understand that you're interested in selling us this\noperating system, but compare it to ours. We can't possibly take such\na retrograde step.\"\n"},{"id":"88674","messageId":"48B4A10F.10601@gmail.com","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808260959000.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2008-08-27T00:34:23Z","receivedAt":"2008-08-27T00:34:23Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Linus Torvalds wrote:\n\n> \n> So live with it, and just add the \n> \n> \tPATH=\"$PATH:$(git --exec-path)\"\n> \n> as a \"compatibility layer\" to your own setup already. There is no \n> downside, and I think there _is_ a big upside, and no, it's not just about \n> \"/usr/bin\" being smaller.\n\nActually, this is acceptable since I set gitexecdir to $(bindir) in my \nmake invocation.\n\n*BUT* the recent discussion of not creating the hardlinks in \ngit/core/libexec, introducing obnoxious warnings when using the dashed \nforms, and eventually having the git binary error when invoked as a \ndashed command is NOT acceptable. The discussion that happened in \nNovember and December 2006 was only about about moving the executables \nout of /usr/bin, not the completely disabling of the dashed forms for \nthose users and distributions that want them.\n"},{"id":"88677","messageId":"76718490808261924j1ddae535tdfb671dd9d3298aa@mail.gmail.com","threadId":"15184","inReplyTo":"20080826210318.GA6305@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-08-27T02:24:37Z","receivedAt":"2008-08-27T02:24:37Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Tue, Aug 26, 2008 at 5:03 PM, Jeff King wrote:\n> I was slightly negative on the change at the time of \"/usr/bin vs\n> /usr/libexec/git-core\" and I planned to put \"git --exec-path\" in my\n> PATH. But I gave the new way a try, and I have not been very bothered.\n> So let me say that I really don't care much what happens with libexec,\n> and you can hold me to that when the next flame-war breaks out if such a\n> change is implemented. Now you have three opinions. :)\n\n+1 on removing the links and I will say this: this change finally\nmotivated me to switch my login shell from tcsh (12 years I've been\nusing it!) to bash so I could use the completions and I'm happier for\nit. So thank you git. :-)\n\nj.\n"},{"id":"88691","messageId":"48B5098E.748.A598B62@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"15184","inReplyTo":"20080826164526.GM26610@one.firstfloor.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2008-08-27T06:00:17Z","receivedAt":"2008-08-27T06:00:17Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 26 Aug 2008 at 18:45, Andi Kleen wrote:\n\n> git.... what? 140-something commands? etc.etc.\n> \n\nHi!\n\nJust let me throw in one thought:\n\nWhether files in /usr/bin, or command completions: Long linear lists are a thing \nhumans don't like. For the directory issue, one could (assuming a two-level \nhierarchy) take the square root of the number of binaries and create that many \ndirectories to put the files in (in theory). Likewise for git one could \ndeduce the list by making two levels out of one (i.e. sub-sommands).\n\nIn HP-UX many commands (or \"subsystems\") use /opt//{bin,sbin} to place \ntheir binaries. PATH usually does not contain all of them. That's against Linux \nphilosophy I think, and I really don't like huge PATHs, but it may be one solution \nto reduce the size of linear lists. It won't help against the git issue \ndirectly, however.\n\nRegards,\nUlrich\n"},{"id":"88693","messageId":"48B50A84.29823.A5D4BB6@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","threadId":"15184","inReplyTo":"20080826172742.GN26610@one.firstfloor.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Ulrich Windl","fromEmail":"ulrich.windl@rz.uni-regensburg.de","sentAt":"2008-08-27T06:04:23Z","receivedAt":"2008-08-27T06:04:23Z","isPatch":false,"sender":{"key":"ulrich.windl@rz.uni-regensburg.de","avatar":null},"body":"On 26 Aug 2008 at 19:27, Andi Kleen wrote:\n\n[...]\n> I was assuming someone thinking about using git. At some point\n> they will do the git thing and be scared away.\n[...]\n\nHi!\n\nHonestly I think, the user will type \"git\" first.\n\nUlrich\n"},{"id":"88698","messageId":"20080827094231.51d00b31@hyperion.delvare","threadId":"15184","inReplyTo":"48B46443.6000800@kernel.org","subject":"Re: [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jean Delvare","fromEmail":"khali@linux-fr.org","sentAt":"2008-08-27T07:42:31Z","receivedAt":"2008-08-27T07:42:31Z","isPatch":false,"sender":{"key":"khali@linux-fr.org","avatar":"https://gravatar.com/avatar/f8d1a5b65d416951f857a72a21321540bc2b4350e1c5243caa0c620f95b01b6e?d=mp&s=160"},"body":"Hi Peter,\n\nOn Tue, 26 Aug 2008 13:14:59 -0700, H. Peter Anvin wrote:\n> Jean Delvare wrote:\n> > \n> > Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but\n> > to the silent majority I am a proud member of, it was. (I'm not saying\n> > that the path that was taken to get there was optimal, just that the\n> > goal was sound.)\n> \n> You keep trying to use the Nixon argument (\"silent majority.\") You *do* \n> know that it was a rhetorical device used by Nixon's speechwriters to \n> push ahead with policies despite compact opposition, don't you?\n\nNo, I don't. What I know is that people who are happy about a decision\nusually don't tell about it and just take it for good and granted and\nmove to something else. You almost always only hear people who are\nunhappy about decisions. Which means that comparing the amount of\nnoise made by the two groups is not fair. For a fair comparison, you\nneed to ask before doing the change, or if you have already done it, you\nhave to revert it and see if it generates more complaints than the\noriginal change did (and even that is not totally fair, as some people\nwill complain because of the double change rather than the decision\nitself.)\n\nAnyway, the \"silent majority\" is no longer silent. If it were, this\ndiscussion thread wouldn't be 60 posts long.\n\n> As far as I can tell, most of the arguments in favour came from fanbois \n> of $OTHER_SCM which went along the lines of \"why does git need all this \n> stuff in /usr/bin, when $OTHER_SCM doesn't?\" It had nothing to do with \n> reality, of course; it was just a difference between git and $OTHER_SCM \n> which they choose to pick on.\n\nI see no point in limiting ourselves to SCMs. There are many other\ncategories of software which have internal commands. I'm using many of\nthese every day: trac, quilt, lftp. The fact is that none of these have\na hundred extra entries in /usr/bin as git does. trac has one, quilt\nhas two, lftp has three. So, git does (or used to do) things in a way\nthat differs from most other tools do.\n\nOTOH, speaking of SCMs, I clearly remember of an old SCM (was it RCS?)\nwhich exposed internal commands \"ci\" and \"co\" in the PATH and that\ncaused great frustration to me several times (notice how near the C and\nV are on the keyboard.) I was very happy to see that this namespace\npollution was gone with CVS. Not so happy to see that it was partly back\nwith SVN (9 binaries in /usr/bin). And frankly unhappy to see that it\nwas one order of magnitude worse with git.\n\nOK, I'm done with this discussion now. I'm sure everyone involved has\nbetter things to spend their time on.\n\n-- \nJean Delvare\n"},{"id":"88697","messageId":"48B50574.6020502@op5.se","threadId":"15184","inReplyTo":"20080826192039.5ffa6eec@hyperion.delvare","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-08-27T07:42:44Z","receivedAt":"2008-08-27T07:42:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jean Delvare wrote:\n> On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:\n>> At Tue, 26 Aug 2008 18:23:49 +0200,\n>> Jean Delvare wrote:\n>>> On Tue, 26 Aug 2008 16:59:58 +0100, David Woodhouse wrote:\n>>>> On Tue, 2008-08-26 at 11:34 -0400, Kristian Høgsberg wrote:\n>>>>> It's pretty normal to see opponents of a decision like this complain\n>>>>> loudly when it lands on their system, whereas the silent majority in\n>>>>> favour will be happy to see the change finally implemented but reluctant\n>>>>> to stir up the discussion again.\n>>>>>\n>>>>> I don't think new arguments are brought to the discussion, just new\n>>>>> people, who are temporarily inconvened by a change towards sanity.\n>>>> Nice emotive response, especially the subtle but unsubstantiated 'silent\n>>>> majority in favour' bit -- but you forgot the part where you were\n>>>> supposed to actually point out a tangible benefit which is achieved by\n>>>> breaking compatibility like this.\n>>>>\n>>>> And no, reducing the size of /usr/bin by a tiny fraction isn't really a\n>>>> worthwhile benefit -- in reality, the 'silent majority' really couldn't\n>>>> give a monkey's left testicle about that, and breakage caused by the\n>>>> gratuitous change _far_ outweighs any minuscule improvement.\n>>> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but\n>>> to the silent majority I am a proud member of, it was. (I'm not saying\n>>> that the path that was taken to get there was optimal, just that the\n>>> goal was sound.)\n>>>\n>>> I just can't think of any other tool which installs over 100 binaries\n>>> (or scripts, that's the same) in /usr/bin. Can you?\n>> netpbm has almost 300 in /usr/bin.\n> \n> Ouch. (I guess I shouldn't have asked.)\n> \n> Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to\n> get rid of netpbm.\n> \n\nnetpbm-progs (the rpm containing all the 320 programs in /usr/bin) is\nrequired for xmlto to function properly, which in turn is necessary\nto build the git documentation.\n\nThis is on Fedora 9, btw.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"88702","messageId":"48B50945.7020709@kernel.org","threadId":"15184","inReplyTo":"48B5098E.748.A598B62@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"H. Peter Anvin","fromEmail":"hpa@kernel.org","sentAt":"2008-08-27T07:59:01Z","receivedAt":"2008-08-27T07:59:01Z","isPatch":false,"sender":{"key":"hpa@kernel.org","avatar":null},"body":"Ulrich Windl wrote:\n> \n> In HP-UX many commands (or \"subsystems\") use /opt//{bin,sbin} to place \n> their binaries. PATH usually does not contain all of them. That's against Linux \n> philosophy I think, and I really don't like huge PATHs, but it may be one solution \n> to reduce the size of linear lists. It won't help against the git issue \n> directly, however.\n> \n\n/opt is part of the Filesystem Hierarchy Standard which defines layouts \non Linux systems. It is generally not used for binaries included in \ndistributions or otherwise managed via distribution package managers, \nhowever.\n\n\t-hpa\n"},{"id":"88704","messageId":"20080827102131.49e018ee@hyperion.delvare","threadId":"15184","inReplyTo":"48B50574.6020502@op5.se","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jean Delvare","fromEmail":"khali@linux-fr.org","sentAt":"2008-08-27T08:21:31Z","receivedAt":"2008-08-27T08:21:31Z","isPatch":false,"sender":{"key":"khali@linux-fr.org","avatar":"https://gravatar.com/avatar/f8d1a5b65d416951f857a72a21321540bc2b4350e1c5243caa0c620f95b01b6e?d=mp&s=160"},"body":"On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote:\n> Jean Delvare wrote:\n> > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:\n> >> netpbm has almost 300 in /usr/bin.\n> > \n> > Ouch. (I guess I shouldn't have asked.)\n> > \n> > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to\n> > get rid of netpbm.\n> > \n> \n> netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is\n> required for xmlto to function properly, which in turn is necessary\n> to build the git documentation.\n> \n> This is on Fedora 9, btw.\n\nOn openSuse systems it is required by sax2-gui only. But just because\nit is used by these 2 packages doesn't mean that ImageMagick's convert\ncan't be used instead. Someone would need to check what exactly xmlto\nand sax2-gui use in netpbm and whether convert could be used instead.\nI'd do if I only I had the time... :/\n\n-- \nJean Delvare\n"},{"id":"88706","messageId":"48B51133.1030400@op5.se","threadId":"15184","inReplyTo":"48B46443.6000800@kernel.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-08-27T08:32:51Z","receivedAt":"2008-08-27T08:32:51Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"H. Peter Anvin wrote:\n> Jean Delvare wrote:\n>>\n>> Reducing /usr/bin in size was totally worthwhile. Maybe not to you, but\n>> to the silent majority I am a proud member of, it was. (I'm not saying\n>> that the path that was taken to get there was optimal, just that the\n>> goal was sound.)\n>>\n> \n> You keep trying to use the Nixon argument (\"silent majority.\") You *do* \n> know that it was a rhetorical device used by Nixon's speechwriters to \n> push ahead with policies despite compact opposition, don't you?\n> \n> As far as I can tell, most of the arguments in favour came from fanbois \n> of $OTHER_SCM which went along the lines of \"why does git need all this \n> stuff in /usr/bin, when $OTHER_SCM doesn't?\" It had nothing to do with \n> reality, of course; it was just a difference between git and $OTHER_SCM \n> which they choose to pick on.\n> \n\nWell, some new users both here and on #git have been slightly bewildered\nabout the number of commands the default bash-completion show when typing\ngit. If anything, the move is long overdue, or should have\nwaited until 2.0 where people would expect to have to re-learn quite a lot.\n\nThere were, initially, two drawbacks with having the git- outside\nthe users $PATH. The first was performance when used from scripts, which\nwas addressed in November 2005 when the git wrapper was rewritten in C,\nprior to the 1.0 release.\nThe second is the shell-completion, which was added in September 2006,\nprior to the 1.5 release.\n\nIn retrospect, it would probably have been a good thing to make the move\nwith the 1.0 release (which would likely have caused the bash and zsh\ncompletion scripts to pop into existence a lot earlier than 1.4.2), or\nin 1.5, when both reasons for keeping the commands in the path were simply\nnot there anymore. 1.5 was also informally nicknamed \"the UI release\", so\nit would have sort of fitted in there, while 1.0 was the first \"this is\nhow git will work for the foreseeable future\" release, so anything before\n1.0 could be considered beta software with a very flexible and fast-moving\nUI.\n\nWorth remembering for the future perhaps, although I know it's easy to\noverlook the fact that the inertia of the userbase grows exponentially\nwith the headcount of the same.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"88708","messageId":"20080827090925.GB14222@diana.vm.bytemark.co.uk","threadId":"15184","inReplyTo":"vpqiqtnsasb.fsf@bauges.imag.fr","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-08-27T09:09:25Z","receivedAt":"2008-08-27T09:09:25Z","isPatch":true,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-08-26 23:53:40 +0200, Matthieu Moy wrote:\n\n> Petr Baudis writes:\n>\n> > git still shows way too many commands, some of them are\n> > clearly plumbing.\n>\n> Is it possible to have the completion not show them by default, but\n> fall back to them if no other completion is found?\n\nI don't know if it's possible, but it sounds like a great idea.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"88719","messageId":"m3prnumysy.fsf@maximus.localdomain","threadId":"15184","inReplyTo":"1219764860.4471.13.camel@gaara.bos.redhat.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Krzysztof Halasa","fromEmail":"khc@pm.waw.pl","sentAt":"2008-08-27T12:23:41Z","receivedAt":"2008-08-27T12:23:41Z","isPatch":false,"sender":{"key":"khc@pm.waw.pl","avatar":null},"body":"Kristian Høgsberg writes:\n\n> It's pretty normal to see opponents of a decision like this complain\n> loudly when it lands on their system, whereas the silent majority in\n> favour will be happy to see the change finally implemented but reluctant\n> to stir up the discussion again.\n\nI'm \"sure\" the silent majority don't care at all. Git is a program\nmostly for a specialized group of people who are perfectly capable of\nusing either model or customizing the installation at will.\n\nIt may be a correctness issue with pro and cons for each model\n(something along the lines of \"how many devils...\"), but it doesn't\nmatter for the (I'm sure) \"silent majority\" in practice at\nall. Writing this email (let alone reading them all) takes more time\nthan customizing git config.\n-- \nKrzysztof Halasa\n"},{"id":"88724","messageId":"48B5697B.3030405@kernel.org","threadId":"15184","inReplyTo":"76718490808261924j1ddae535tdfb671dd9d3298aa@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"H. Peter Anvin","fromEmail":"hpa@kernel.org","sentAt":"2008-08-27T14:49:31Z","receivedAt":"2008-08-27T14:49:31Z","isPatch":false,"sender":{"key":"hpa@kernel.org","avatar":null},"body":"Jay Soffian wrote:\n> On Tue, Aug 26, 2008 at 5:03 PM, Jeff King wrote:\n>> I was slightly negative on the change at the time of \"/usr/bin vs\n>> /usr/libexec/git-core\" and I planned to put \"git --exec-path\" in my\n>> PATH. But I gave the new way a try, and I have not been very bothered.\n>> So let me say that I really don't care much what happens with libexec,\n>> and you can hold me to that when the next flame-war breaks out if such a\n>> change is implemented. Now you have three opinions. :)\n> \n> +1 on removing the links and I will say this: this change finally\n> motivated me to switch my login shell from tcsh (12 years I've been\n> using it!) to bash so I could use the completions and I'm happier for\n> it. So thank you git. :-)\n> \n\nSpeaking as a tcsh user, I'm not switching until bash gets the \nequivalent functionality as tcsh aliases, in particular the ability to \nselectively disable wildcard expansion on a command-by-command basis.\n\n\t-hpa\n"},{"id":"88725","messageId":"Pine.LNX.4.64.0808271710480.22151@vixen.sonytel.be","threadId":"15184","inReplyTo":"20080827102131.49e018ee@hyperion.delvare","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Geert Uytterhoeven","fromEmail":"geert.uytterhoeven@sonycom.com","sentAt":"2008-08-27T15:14:36Z","receivedAt":"2008-08-27T15:14:36Z","isPatch":false,"sender":{"key":"geert.uytterhoeven@sonycom.com","avatar":null},"body":"On Wed, 27 Aug 2008, Jean Delvare wrote:\n> On Wed, 27 Aug 2008 09:42:44 +0200, Andreas Ericsson wrote:\n> > Jean Delvare wrote:\n> > > On Tue, 26 Aug 2008 18:50:25 +0200, Takashi Iwai wrote:\n> > >> netpbm has almost 300 in /usr/bin.\n> > > \n> > > Ouch. (I guess I shouldn't have asked.)\n> > > \n> > > Does netpbm do anything convert (ImageMagick) doesn't? I'd be happy to\n> > > get rid of netpbm.\n> > \n> > netpbm-progs (the rpm containing all the 320 programs in /usr/bin) is\n> > required for xmlto to function properly, which in turn is necessary\n> > to build the git documentation.\n> > \n> > This is on Fedora 9, btw.\n> \n> On openSuse systems it is required by sax2-gui only. But just because\n> it is used by these 2 packages doesn't mean that ImageMagick's convert\n> can't be used instead. Someone would need to check what exactly xmlto\n> and sax2-gui use in netpbm and whether convert could be used instead.\n> I'd do if I only I had the time... :/\n\nGreat, let's start a witch (nazi? ;-) hunt on any package installing more than\n$n binaries in /usr/bin, and any packages depending on it...\n\nGet used to the `choice' you and I have between netpbm and ImageMagick (and\nwhatever other image manipulation tool), just like the choice between\n`git' and `git-'.\n\nNow, let's get back to topic...\n\nWith kind regards,\n\nGeert Uytterhoeven\nSoftware Architect\n\nSony Techsoft Centre Europe\nThe Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium\n\nPhone: +32 (0)2 700 8453\nFax: +32 (0)2 700 8622\nE-mail: Geert.Uytterhoeven@sonycom.com\nInternet: http://www.sony-europe.com/\n\nA division of Sony Europe (Belgium) N.V.\nVAT BE 0413.825.160 · RPR Brussels\nFortis · BIC GEBABEBB · IBAN BE41293037680010"},{"id":"88727","messageId":"alpine.DEB.1.10.0808271126190.10784@gandalf.stny.rr.com","threadId":"15184","inReplyTo":"23DFA9EC-9523-4179-BA3C-ACBDB82953DF@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2008-08-27T15:27:04Z","receivedAt":"2008-08-27T15:27:04Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"\nOn Tue, 26 Aug 2008, Perry Wagle wrote:\n> \n> I'm trying to upgrade the git that our scripts use, and having the \n> users modify their paths doesn't work.\n> \n> Not that horrible to fix some other way, but still a rude thing to \n> wake up to one day. (ie, today)\n> \n\nDid you see the yellow bulldozer coming at your house while brushing your \nteeth?\n\n-- Steve\n"},{"id":"88757","messageId":"20080827191419.GC18340@parisc-linux.org","threadId":"15184","inReplyTo":"48B5098E.748.A598B62@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthew Wilcox","fromEmail":"matthew@wil.cx","sentAt":"2008-08-27T19:14:19Z","receivedAt":"2008-08-27T19:14:19Z","isPatch":false,"sender":{"key":"matthew@wil.cx","avatar":null},"body":"On Wed, Aug 27, 2008 at 08:00:17AM +0200, Ulrich Windl wrote:\n> In HP-UX many commands (or \"subsystems\") use /opt//{bin,sbin} to place \n> their binaries. PATH usually does not contain all of them. That's against Linux \n> philosophy I think, and I really don't like huge PATHs, but it may be one solution \n> to reduce the size of linear lists. It won't help against the git issue \n> directly, however.\n\nIn HP-UX, the default shell has a line length limit that is smaller than\nthe length of $PATH. Be in awe of enterprise scalability.\n\n-- \nMatthew Wilcox\t\t\t\tIntel Open Source Technology Centre\n\"Bill, look, we understand that you're interested in selling us this\noperating system, but compare it to ours. We can't possibly take such\na retrograde step.\"\n"},{"id":"88763","messageId":"B83CC7EA-C77E-45CA-B9C5-FC81A8C0C9A5@cs.indiana.edu","threadId":"15184","inReplyTo":"48B5098E.748.A598B62@Ulrich.Windl.rkdvmks1.ngate.uni-regensburg.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-27T19:43:23Z","receivedAt":"2008-08-27T19:43:23Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"On Aug 26, 2008, at 11:00 PM, Ulrich Windl wrote:\n> On 26 Aug 2008 at 18:45, Andi Kleen wrote:\n>> git.... what? 140-something commands? etc.etc.\n> Whether files in /usr/bin, or command completions: Long linear lists \n> are a thing\n> humans don't like.\n\nBash and other shells use hash tables to store the commands in the PATH.\n\nDoing git- was shocking to me at first, but it also showed me a \nlist of commands for me to learn.\n\nNow I guess that when everything's fixed up, I'll have to put in a \nspace instead of a dash to get exactly the same thing.\n\nWhat difference did changing the dash to a space make?\n\n-- Perry\n"},{"id":"88766","messageId":"20080827195019.GA9962@sigill.intra.peff.net","threadId":"15184","inReplyTo":"B83CC7EA-C77E-45CA-B9C5-FC81A8C0C9A5@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T19:50:19Z","receivedAt":"2008-08-27T19:50:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote:\n\n> Doing git- was shocking to me at first, but it also showed me a list \n> of commands for me to learn.\n>\n> Now I guess that when everything's fixed up, I'll have to put in a space \n> instead of a dash to get exactly the same thing.\n>\n> What difference did changing the dash to a space make?\n\nDid you miss the part of the thread about how it's not exactly the same\nthing, but rather substantially fewer commands (and there is even\nadditional discussion about _which_ commands)?\n\n-Peff\n"},{"id":"88767","messageId":"38B725C0-40C3-496C-AAD4-4EA65E3085F5@cs.indiana.edu","threadId":"15184","inReplyTo":"20080827195019.GA9962@sigill.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-27T19:54:56Z","receivedAt":"2008-08-27T19:54:56Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 27, 2008, at 12:50 PM, Jeff King wrote:\n\n> On Wed, Aug 27, 2008 at 12:43:23PM -0700, Perry Wagle wrote:\n>\n>> Doing git- was shocking to me at first, but it also showed me \n>> a list\n>> of commands for me to learn.\n>>\n>> Now I guess that when everything's fixed up, I'll have to put in a \n>> space\n>> instead of a dash to get exactly the same thing.\n>>\n>> What difference did changing the dash to a space make?\n>\n> Did you miss the part of the thread about how it's not exactly the \n> same\n> thing, but rather substantially fewer commands (and there is even\n> additional discussion about _which_ commands)?\n\nI guess I did. Being an optimist, I wouldn't expect the tab \ncompletion to *lie* and leave things out.\n\n-- Perry\n"},{"id":"88773","messageId":"48B5B7F3.4080803@pobox.com","threadId":"15184","inReplyTo":"20080826210631.GC3812@1wt.eu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2008-08-27T20:24:19Z","receivedAt":"2008-08-27T20:24:19Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Willy Tarreau wrote:\n> The problem is not caused by the number of commands, but by their\n> complexity. I need completion because it's hard to type their very\n> long names without making mistakes (not counting the long options).\n> \"git am\" is fine with me, but \"git format-patch\" is quite boring to\n> type. It's also interesting to note that short names are currently\n> in place for less commonly used commands : git-rm, git-mv, git-gc.\n\nIndeed.\n\nAlso, I type \"git-diff-tree\" quite a lot.\n\nMy fingers find that\n\n\tgit SPACE diff DASH tree\n\nis slower and less consistent than\n\n\tgit DASH diff DASH tree\n\nThe same with git-format-patch... We are going from \"all dashes\" to \"a \nmix of space and dashes\" which is increasing inconsistency.\n\n\tJeff\n"},{"id":"88774","messageId":"20080827202707.GA25233@coredump.intra.peff.net","threadId":"15184","inReplyTo":"48B5B7F3.4080803@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T20:27:07Z","receivedAt":"2008-08-27T20:27:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:\n\n> Indeed.\n>\n> Also, I type \"git-diff-tree\" quite a lot.\n>\n> My fingers find that\n>\n> \tgit SPACE diff DASH tree\n>\n> is slower and less consistent than\n>\n> \tgit DASH diff DASH tree\n>\n> The same with git-format-patch... We are going from \"all dashes\" to \"a \n> mix of space and dashes\" which is increasing inconsistency.\n\nI have also found the SPACE-DASH slightly harder to type. However, I'm\ncurious: what are you doing frequently from the commandline with\ngit-diff-tree that is not just as easily done with git-diff?\n\n-Peff\n"},{"id":"88778","messageId":"48B5BB35.8090606@pobox.com","threadId":"15184","inReplyTo":"20080827202707.GA25233@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2008-08-27T20:38:13Z","receivedAt":"2008-08-27T20:38:13Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Jeff King wrote:\n> On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:\n> \n>> Indeed.\n>>\n>> Also, I type \"git-diff-tree\" quite a lot.\n>>\n>> My fingers find that\n>>\n>> \tgit SPACE diff DASH tree\n>>\n>> is slower and less consistent than\n>>\n>> \tgit DASH diff DASH tree\n>>\n>> The same with git-format-patch... We are going from \"all dashes\" to \"a \n>> mix of space and dashes\" which is increasing inconsistency.\n> \n> I have also found the SPACE-DASH slightly harder to type. However, I'm\n> curious: what are you doing frequently from the commandline with\n> git-diff-tree that is not just as easily done with git-diff?\n\nI use it to spit out a patch for a specific commit:\n\n\tgit-diff-tree -p $COMMIT\n\nThough probably someone will now come along and tell me I'm am \nold-timer, and there is a shorter command that accomplishes the same \nthing :)\n\nRegards,\n\n\tJeff\n"},{"id":"88780","messageId":"48B5BC5F.4070209@kernel.org","threadId":"15184","inReplyTo":"38B725C0-40C3-496C-AAD4-4EA65E3085F5@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"H. Peter Anvin","fromEmail":"hpa@kernel.org","sentAt":"2008-08-27T20:43:11Z","receivedAt":"2008-08-27T20:43:11Z","isPatch":false,"sender":{"key":"hpa@kernel.org","avatar":null},"body":"Perry Wagle wrote:\n>> Did you miss the part of the thread about how it's not exactly the \n>> same thing, but rather substantially fewer commands (and there is even\n>> additional discussion about _which_ commands)?\n> \n> I guess I did. Being an optimist, I wouldn't expect the tab \n> completion to *lie* and leave things out.\n\nYes, that sounds, ahem, rude.\n\n\t-hpa\n"},{"id":"88782","messageId":"alpine.LFD.1.10.0808271345340.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"48B5B7F3.4080803@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-27T20:50:50Z","receivedAt":"2008-08-27T20:50:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Aug 2008, Jeff Garzik wrote:\n> \n> Also, I type \"git-diff-tree\" quite a lot.\n\nWhy?\n\nI'd suggest you just type \"git diff\" (if you diff two trees) or \"git show\" \n(if you want to see just one commit) instead.\n\nThere is _no_ reason to use diff-tree, it's purely a historical command \ndue to how the implementation was done (ie diffing two trees is a very \ndifferent operation from diffing against the index when looked at from an \nimplementation standpoint).\n\n\t\tLinus\n"},{"id":"88781","messageId":"20080827205314.GA3198@sigill.intra.peff.net","threadId":"15184","inReplyTo":"48B5BB35.8090606@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T20:53:14Z","receivedAt":"2008-08-27T20:53:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:\n\n> I use it to spit out a patch for a specific commit:\n>\n> \tgit-diff-tree -p $COMMIT\n>\n> Though probably someone will now come along and tell me I'm am old-timer, \n> and there is a shorter command that accomplishes the same thing :)\n\nActually, that is something that diff-tree does better (a single\ntree-ish with git-diff is \"compare against working tree\"). To do it with\ngit-diff you would have to use the obscure (and not very shell-friendly)\nsyntax:\n\n git diff $COMMIT^!\n\nAlthough interactively, I tend to use \"git show\" for this purpose,\nthough perhaps you intentionally don't want to see the commit message.\n\nAnyway, thank you for satisfying my curiosity.\n\n-Peff\n"},{"id":"88783","messageId":"20080827210555.GF18340@parisc-linux.org","threadId":"15184","inReplyTo":"48B5BB35.8090606@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthew Wilcox","fromEmail":"matthew@wil.cx","sentAt":"2008-08-27T21:05:56Z","receivedAt":"2008-08-27T21:05:56Z","isPatch":false,"sender":{"key":"matthew@wil.cx","avatar":null},"body":"On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:\n> I use it to spit out a patch for a specific commit:\n> \n> \tgit-diff-tree -p $COMMIT\n> \n> Though probably someone will now come along and tell me I'm am \n> old-timer, and there is a shorter command that accomplishes the same \n> thing :)\n\ngit-show -p $COMMIT ?\n\nIt also gives you the commit message, but that's not a hardship usually\n...\n\n-- \nMatthew Wilcox\t\t\t\tIntel Open Source Technology Centre\n\"Bill, look, we understand that you're interested in selling us this\noperating system, but compare it to ours. We can't possibly take such\na retrograde step.\"\n"},{"id":"88784","messageId":"20080827211326.GI11734@cs181140183.pp.htv.fi","threadId":"15184","inReplyTo":"20080827210555.GF18340@parisc-linux.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Adrian Bunk","fromEmail":"bunk@kernel.org","sentAt":"2008-08-27T21:13:26Z","receivedAt":"2008-08-27T21:13:26Z","isPatch":false,"sender":{"key":"bunk@kernel.org","avatar":null},"body":"On Wed, Aug 27, 2008 at 03:05:56PM -0600, Matthew Wilcox wrote:\n> On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:\n> > I use it to spit out a patch for a specific commit:\n> > \n> > \tgit-diff-tree -p $COMMIT\n> > \n> > Though probably someone will now come along and tell me I'm am \n> > old-timer, and there is a shorter command that accomplishes the same \n> > thing :)\n> \n> git-show -p $COMMIT ?\n> \n> It also gives you the commit message, but that's not a hardship usually\n> ...\n\nI'm usually using\n git-show --pretty=oneline $COMMIT\n\ncu\nAdrian\n\nBTW: I'd love to get a --pretty=noline\n\n-- \n\n \"Is there not promise of rain?\" Ling Tan asked suddenly out\n of the darkness. There had been need of rain for many days.\n \"Only a promise,\" Lao Er said.\n Pearl S. Buck - Dragon Seed\n"},{"id":"88785","messageId":"alpine.DEB.1.10.0808271717190.19923@gandalf.stny.rr.com","threadId":"15184","inReplyTo":"48B5BC5F.4070209@kernel.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2008-08-27T21:19:42Z","receivedAt":"2008-08-27T21:19:42Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"\nOn Wed, 27 Aug 2008, H. Peter Anvin wrote:\n\n> Perry Wagle wrote:\n> >> Did you miss the part of the thread about how it's not exactly the \n> >> same thing, but rather substantially fewer commands (and there is even\n> >> additional discussion about _which_ commands)?\n> > \n> > I guess I did. Being an optimist, I wouldn't expect the tab \n> > completion to *lie* and leave things out.\n> \n> Yes, that sounds, ahem, rude.\n\n\nYes, they are all a bunch of Nazi git fanatics, that Hitler himself would \nhave used the space version of git. He sent the Jews off to the \nconcentration camps because they insisted on using the dashes.\n\nThere, we have a Hitler reference.\n\nCAN WE PLEASE LET THIS THREAD DIE!\n\n-- Steve\n"},{"id":"88787","messageId":"20080827212217.GA3554@sigill.intra.peff.net","threadId":"15184","inReplyTo":"20080827211326.GI11734@cs181140183.pp.htv.fi","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-27T21:22:17Z","receivedAt":"2008-08-27T21:22:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 12:13:26AM +0300, Adrian Bunk wrote:\n\n> BTW: I'd love to get a --pretty=noline\n\nHow about --pretty=format: ?\n\n-Peff\n"},{"id":"88788","messageId":"alpine.LFD.1.10.0808271420210.3363@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"48B5BB35.8090606@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-27T21:23:24Z","receivedAt":"2008-08-27T21:23:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 27 Aug 2008, Jeff Garzik wrote:\n> \n> I use it to spit out a patch for a specific commit:\n> \n> \tgit-diff-tree -p $COMMIT\n\nUse\n\n\tgit show $COMMIT\n\ninstead, which is shorter and gives you the log too, and uses a pager by \ndefault. And defaults to HEAD, so you don't even need to say $COMMIT if \nyou want to see the top one. IOW, much nicer is so many ways.\n\nYeah, the \"much nicer\" obviously does mean \"different\". If you _rely_ on \nthe fact that you don't get a pager (you just want to scroll youself), or \nyou really don't want to see what the commit message was all about, then \n'git diff-tree' is obviously \"better\".\n\nBut at least personally, I really don't know when I last wanted to have \nanything else than 'git show' for showing a commit.\n\n\t\t\tLinus\n"},{"id":"88802","messageId":"20080827222945.GT11734@cs181140183.pp.htv.fi","threadId":"15184","inReplyTo":"20080827212217.GA3554@sigill.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Adrian Bunk","fromEmail":"bunk@kernel.org","sentAt":"2008-08-27T22:29:45Z","receivedAt":"2008-08-27T22:29:45Z","isPatch":false,"sender":{"key":"bunk@kernel.org","avatar":null},"body":"On Wed, Aug 27, 2008 at 05:22:17PM -0400, Jeff King wrote:\n> On Thu, Aug 28, 2008 at 12:13:26AM +0300, Adrian Bunk wrote:\n> \n> > BTW: I'd love to get a --pretty=noline\n> \n> How about --pretty=format: ?\n\nThanks, that does the trick. :-)\n\n> -Peff\n\ncu\nAdrian\n\n-- \n\n \"Is there not promise of rain?\" Ling Tan asked suddenly out\n of the darkness. There had been need of rain for many days.\n \"Only a promise,\" Lao Er said.\n Pearl S. Buck - Dragon Seed\n"},{"id":"88809","messageId":"20080827225233.GA11005@flint.arm.linux.org.uk","threadId":"15184","inReplyTo":"20080827001705.GG23698@parisc-linux.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2008-08-27T22:52:33Z","receivedAt":"2008-08-27T22:52:33Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:\n> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:\n> > When I hear something like what David Woodhouse said in this thread, I\n> > should be feeling \"People -- those of you who claimed to be the silent\n> > majority -- see, I told you so! This is a very bad move\".\n> > \n> > But I can't. People who complain _now_ just annoy me even more. Why\n> > weren't you defending the backward compatibility with me, which you seem\n> > to value it so much, perhaps even more than I did back then? Why are you\n> > wasting our time bringing it up again, instead of joining the discussion\n> > when it _mattered_ back then?\n> \n> We didn't know the conversation was going on. Why should we? We only\n> use the tool, not develop it. I'm also not on the mailing lists for\n> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\n> any of the dozens of other programs I use on a daily basis.\n\nWell said Matthew, as a git _user_ I completely agree.\n\nI only found out myself when it got installed on master.kernel.org, and\nthings that had worked fine for ages suddenly stopped working with no\nclear solution. Useless documentation which refers to the commands\nwhich didn't seem to be in existence anymore was just, to put it mildly,\ninfuriating, and provided no answer.\n\nThat said, I've now updated all my scripts to not use the dashed version,\nincluding on my local machines (which are still using git 1.5.4.x); the\nonly thing is I can't get out of the habbit of typing 'git-diff-tree -u'\nif I want to see a single commit, or 'git-diff-files -u' if I want to\nsee (almost) everything in my working directory, or 'git-am'. The\nsolution is trivial for when the dashed commands finally go away.\n\nalias git-am='git am'\nalias git-diff-files='git diff-files'\n\netc. in ~/.bashrc So it's no real big hastle for me anymore.\n\n-- \nRussell King\n"},{"id":"88810","messageId":"20080827230903.GB11005@flint.arm.linux.org.uk","threadId":"15184","inReplyTo":"alpine.DEB.1.10.0808271126190.10784@gandalf.stny.rr.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2008-08-27T23:09:03Z","receivedAt":"2008-08-27T23:09:03Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote:\n> \n> On Tue, 26 Aug 2008, Perry Wagle wrote:\n> > \n> > I'm trying to upgrade the git that our scripts use, and having the \n> > users modify their paths doesn't work.\n> > \n> > Not that horrible to fix some other way, but still a rude thing to \n> > wake up to one day. (ie, today)\n> > \n> \n> Did you see the yellow bulldozer coming at your house while brushing your \n> teeth?\n\nThat is not a valid point of view when you're a git user, and things\nsuddenly change from working one day, to not working the next _and_\nyou don't know why the commands you were using have suddenly vanished.\n\nAnd there is no documentation seemingly available to tell you what to\nuse instead.\n\nAnd the available documentation tells you that the commands you were\nusing are still there.\n\nAnd no warnings before hand that the commands you were using were\ndeprecated.\n\n*That* is what is soo abhorrent about this whole business.\n\nHow would you feel if, tomorrow, 'ls', 'tar' etc all gave you \"command\nnot found\", 'man ls' still gave you a man page for ls(1) but the\ncommand was now actually called 'listfiles' instead ?\n\nJust put 'alias ls=listfiles' in your .bashrc !\n\n-- \nRussell King\n Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/\n maintainer of:\n"},{"id":"88815","messageId":"7vd4jukphm.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"alpine.DEB.1.10.0808271717190.19923@gandalf.stny.rr.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-27T23:27:49Z","receivedAt":"2008-08-27T23:27:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Rostedt writes:\n\n> Yes, they are all a bunch of Nazi git fanatics, that Hitler himself would \n> have used the space version of git. He sent the Jews off to the \n> concentration camps because they insisted on using the dashes.\n>\n> There, we have a Hitler reference.\n>\n> CAN WE PLEASE LET THIS THREAD DIE!\n\nYeah, I second this.\n\nThe primary topic has already settled, and we will keep git-foo in libexec\neven for built-ins.\n\nThis offtopic tangent that shouldn't even have started from the beginning\nmust die now. It outlived its usefulness even as a place for people to\nvent.\n"},{"id":"88820","messageId":"7v63pmkozh.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080827001705.GG23698@parisc-linux.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-27T23:38:42Z","receivedAt":"2008-08-27T23:38:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthew Wilcox writes:\n\n> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:\n>> When I hear something like what David Woodhouse said in this thread, I\n>> should be feeling \"People -- those of you who claimed to be the silent\n>> majority -- see, I told you so! This is a very bad move\".\n>> \n>> But I can't. People who complain _now_ just annoy me even more. Why\n>> weren't you defending the backward compatibility with me, which you seem\n>> to value it so much, perhaps even more than I did back then? Why are you\n>> wasting our time bringing it up again, instead of joining the discussion\n>> when it _mattered_ back then?\n>\n> We didn't know the conversation was going on. Why should we? We only\n> use the tool, not develop it. I'm also not on the mailing lists for\n> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\n> any of the dozens of other programs I use on a daily basis.\n\nOh, I wasn't talking to you, or \"we as git users\". The user side of the\ndiscussion has long been over in another thread titled \"[kernel.org users]\nREADME and ChangeLog files\" that was started by HPA, and everybody now\nknows that the conclusion of the discussion was that 1.6.0 transition was\nunderadvertised to the end-user community and caused pain. Sorry about\nthat, but let's leave it behind. What has happend has happened.\n\nThe discussion in this thread was about how to go forward from here, now\nthe transition is over. One of the future directions the transition was\naiming at was removal of git-foo form for built-ins even from the libexec\narea -- I was complaining about David's beating an offtopic dead horse in\nthe above, because it was throwing the thread in an off-track direction,\ndistracting everybody from discussing what was more important, discussing\nconstructively if/how to proceed from here.\n\nNow the primary topic of what to do about built-ins have already settled.\nWe _will_ keep git-foo commands in the libexec area. We won't be removing\nthem.\n\nSo there is no need to worry.\n"},{"id":"88823","messageId":"48B5E822.1020901@pobox.com","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808271420210.3363@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2008-08-27T23:49:54Z","receivedAt":"2008-08-27T23:49:54Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Linus Torvalds wrote:\n> \n> On Wed, 27 Aug 2008, Jeff Garzik wrote:\n>> I use it to spit out a patch for a specific commit:\n>>\n>> \tgit-diff-tree -p $COMMIT\n> \n> Use\n> \n> \tgit show $COMMIT\n> \n> instead, which is shorter and gives you the log too, and uses a pager by \n> default. And defaults to HEAD, so you don't even need to say $COMMIT if \n> you want to see the top one. IOW, much nicer is so many ways.\n> \n> Yeah, the \"much nicer\" obviously does mean \"different\". If you _rely_ on \n> the fact that you don't get a pager (you just want to scroll youself), or \n> you really don't want to see what the commit message was all about, then \n> 'git diff-tree' is obviously \"better\".\n\n'git show' is quite sufficient, as long as I can pipe its output into \npatch(1) or write it to a foo.patch file, which appears to be the case.\n\ngit-diff-tree -p was from the old days; I readily admit being a git \nold-timer :)\n\nAnything that reduces my typing is great, and 'git show' is certainly an \nimprovement in that regard.\n\n\tJeff, typing with a sprained finger (puppies can be a handful)\n"},{"id":"88824","messageId":"48B5E90E.3000601@s5r6.in-berlin.de","threadId":"15184","inReplyTo":"20080827230903.GB11005@flint.arm.linux.org.uk","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2008-08-27T23:53:50Z","receivedAt":"2008-08-27T23:53:50Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Russell King wrote:\n> And no warnings before hand that the commands you were using were\n> deprecated.\n\n(a) They weren't deprecated, they were moved into a different directory.\n\n(b) There have been several announcements of the 1.6.0 prereleases and \nthe 1.6.0 release crossposted. Of course somebody forgot to tell you \nwhat you will learn from these release notes. Unfair.\n\n(c) There do happen unannounced software updates on shell servers over \nwhich you don't have control. Ask for your money back.\n\n(d) \"-\" -> \" \"? Molehill.\n-- \nStefan Richter\n-=====-==--- =--- ===--\nhttp://arcgraph.de/sr/\n"},{"id":"88825","messageId":"F86A1E37-8015-41B5-A462-F044B8D1C2B1@cs.indiana.edu","threadId":"15184","inReplyTo":"7vd4jukphm.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-27T23:53:58Z","receivedAt":"2008-08-27T23:53:58Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:\n\n> Steven Rostedt writes:\n>\n>> Yes, they are all a bunch of Nazi git fanatics, that Hitler himself \n>> would\n>> have used the space version of git. He sent the Jews off to the\n>> concentration camps because they insisted on using the dashes.\n>>\n>> There, we have a Hitler reference.\n>>\n>> CAN WE PLEASE LET THIS THREAD DIE!\n>\n> Yeah, I second this.\n>\n> The primary topic has already settled, and we will keep git-foo in \n> libexec\n> even for built-ins.\n>\n> This offtopic tangent that shouldn't even have started from the \n> beginning\n> must die now. It outlived its usefulness even as a place for people \n> to\n> vent.\n\nI suggested that git used to give the same 143 completions \nthat git would now. This meant that making any arguments \nthat the number was off-putting to newbies did not apply, since you \nhad a same number (143) either way. Putting stuff in libexec does \nnot change the above observation in any fashion.\n\nA response to my observation was that \"not everything will show up in \nthe latter completion\". I balked at that as it distorted the truth. \nIf this distortion would actually take place then I have a real \ncomplaint. Not a tangent.\n\nBut as long as git does the *same* thing as \ngit, I really do not see why you had to go break my \nscripts on a *minor* revision for what amounts to no reason as all.\n\nShells *hash* the PATH, so there is no \"linear list\" issue, and you \nhave the *same* behavior for completion both ways.\n"},{"id":"88826","messageId":"BD6DEBB7-4D1C-43E9-B3D2-B46E42D9771D@cs.indiana.edu","threadId":"15184","inReplyTo":"F86A1E37-8015-41B5-A462-F044B8D1C2B1@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T00:05:33Z","receivedAt":"2008-08-28T00:05:33Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"Oh yeah, sorry. I neglected to mention that my problem was having the \ngit- forms in scripts all over an internal network, and having no \namazingly easy way of fixing them. I don't know who all copied them.\n\n\nOn Aug 27, 2008, at 4:53 PM, Perry Wagle wrote:\n\n>\n> On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:\n>\n>> Steven Rostedt writes:\n>>\n>>> Yes, they are all a bunch of Nazi git fanatics, that Hitler \n>>> himself would\n>>> have used the space version of git. He sent the Jews off to the\n>>> concentration camps because they insisted on using the dashes.\n>>>\n>>> There, we have a Hitler reference.\n>>>\n>>> CAN WE PLEASE LET THIS THREAD DIE!\n>>\n>> Yeah, I second this.\n>>\n>> The primary topic has already settled, and we will keep git-foo in \n>> libexec\n>> even for built-ins.\n>>\n>> This offtopic tangent that shouldn't even have started from the \n>> beginning\n>> must die now. It outlived its usefulness even as a place for \n>> people to\n>> vent.\n>\n> I suggested that git used to give the same 143 \n> completions that git would now. This meant that making \n> any arguments that the number was off-putting to newbies did not \n> apply, since you had a same number (143) either way. Putting stuff \n> in libexec does not change the above observation in any fashion.\n>\n> A response to my observation was that \"not everything will show up \n> in the latter completion\". I balked at that as it distorted the \n> truth. If this distortion would actually take place then I have a \n> real complaint. Not a tangent.\n>\n> But as long as git does the *same* thing as \n> git, I really do not see why you had to go break my \n> scripts on a *minor* revision for what amounts to no reason as all.\n>\n> Shells *hash* the PATH, so there is no \"linear list\" issue, and you \n> have the *same* behavior for completion both ways.\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"88828","messageId":"94a0d4530808271709s4e96c5a7ie6152b2937f2234b@mail.gmail.com","threadId":"15184","inReplyTo":"7v63pmkozh.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-28T00:09:08Z","receivedAt":"2008-08-28T00:09:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 28, 2008 at 2:38 AM, Junio C Hamano wrote:\n> Matthew Wilcox writes:\n>\n>> On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:\n>>> When I hear something like what David Woodhouse said in this thread, I\n>>> should be feeling \"People -- those of you who claimed to be the silent\n>>> majority -- see, I told you so! This is a very bad move\".\n>>>\n>>> But I can't. People who complain _now_ just annoy me even more. Why\n>>> weren't you defending the backward compatibility with me, which you seem\n>>> to value it so much, perhaps even more than I did back then? Why are you\n>>> wasting our time bringing it up again, instead of joining the discussion\n>>> when it _mattered_ back then?\n>>\n>> We didn't know the conversation was going on. Why should we? We only\n>> use the tool, not develop it. I'm also not on the mailing lists for\n>> mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\n>> any of the dozens of other programs I use on a daily basis.\n>\n> Oh, I wasn't talking to you, or \"we as git users\". The user side of the\n> discussion has long been over in another thread titled \"[kernel.org users]\n> README and ChangeLog files\" that was started by HPA, and everybody now\n> knows that the conclusion of the discussion was that 1.6.0 transition was\n> underadvertised to the end-user community and caused pain. Sorry about\n> that, but let's leave it behind. What has happend has happened.\n>\n> The discussion in this thread was about how to go forward from here, now\n> the transition is over. One of the future directions the transition was\n> aiming at was removal of git-foo form for built-ins even from the libexec\n> area -- I was complaining about David's beating an offtopic dead horse in\n> the above, because it was throwing the thread in an off-track direction,\n> distracting everybody from discussing what was more important, discussing\n> constructively if/how to proceed from here.\n>\n> Now the primary topic of what to do about built-ins have already settled.\n> We _will_ keep git-foo commands in the libexec area. We won't be removing\n> them.\n>\n> So there is no need to worry.\n\nStill, if this is the decision, all the documentation should be\nupdated, and people should be discouraged to mention the git-foo\ncommands ever again, otherwise new users would get confused.\n\n-- \nFelipe Contreras\n"},{"id":"88836","messageId":"48B5F502.1090900@pobox.com","threadId":"15184","inReplyTo":"94a0d4530808271709s4e96c5a7ie6152b2937f2234b@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2008-08-28T00:44:50Z","receivedAt":"2008-08-28T00:44:50Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Felipe Contreras wrote:\n> Still, if this is the decision, all the documentation should be\n> updated, and people should be discouraged to mention the git-foo\n> commands ever again, otherwise new users would get confused.\n\n\nTrue.\n\nI scanned my Kernel Hackers' Guide to Git and made sure to kill a few \nstraggling references to dash commands:\n\n\thttp://linux.yyz.us/git-howto.html\n\nEven though my fingers still want to type git DASH foo, feedback from \ngitsters caused me to purge most dash references from the guide a while \nago. I'm surprised the git docs were not updated at the same time I was \nbeing hectored \n\nAnyway, it's a fair point and lets definite get the straggling docs \nconverted and consistent.\n\nComments on the above URL welcome, even if unrelated to the current \ntopic at hand.\n\nThanks,\n\n\tJeff\n"},{"id":"88839","messageId":"alpine.DEB.1.10.0808272117300.1782@gandalf.stny.rr.com","threadId":"15184","inReplyTo":"20080827230903.GB11005@flint.arm.linux.org.uk","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2008-08-28T01:25:47Z","receivedAt":"2008-08-28T01:25:47Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"\nOn Thu, 28 Aug 2008, Russell King wrote:\n\n> On Wed, Aug 27, 2008 at 11:27:04AM -0400, Steven Rostedt wrote:\n> > \n> > On Tue, 26 Aug 2008, Perry Wagle wrote:\n> > > \n> > > I'm trying to upgrade the git that our scripts use, and having the \n> > > users modify their paths doesn't work.\n> > > \n> > > Not that horrible to fix some other way, but still a rude thing to \n> > > wake up to one day. (ie, today)\n> > > \n> > \n> > Did you see the yellow bulldozer coming at your house while brushing your \n> > teeth?\n> \n> That is not a valid point of view when you're a git user, and things\n> suddenly change from working one day, to not working the next _and_\n> you don't know why the commands you were using have suddenly vanished.\n> \n> And there is no documentation seemingly available to tell you what to\n> use instead.\n\nI think you may have totally missed my reference to the beginning of\n\"The Hitchhikers Guide to the Galaxy\", where Aurther saw the Bulldozer \nabout to destroy his house. As he layed in front of the bulldozer, he was \ntold that he had plenty of time to complain. Aurther replied that the \nposting was in some strange hidden location. Kind of like what release \nnotes are.\n\nBut I digress, this thread is totally offtopic for users@kernel.org, can \nwe finally take it off (as I just did).\n\n-- Steve\n\n\n> \n> And the available documentation tells you that the commands you were\n> using are still there.\n> \n> And no warnings before hand that the commands you were using were\n> deprecated.\n> \n> *That* is what is soo abhorrent about this whole business.\n> \n> How would you feel if, tomorrow, 'ls', 'tar' etc all gave you \"command\n> not found\", 'man ls' still gave you a man page for ls(1) but the\n> command was now actually called 'listfiles' instead ?\n> \n> Just put 'alias ls=listfiles' in your .bashrc !\n> \n> -- \n> Russell King\n> Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/\n> maintainer of:\n> \n"},{"id":"88972","messageId":"20080828054352.GB6791@glandium.org","threadId":"15184","inReplyTo":"48B5BB35.8090606@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-08-28T05:43:52Z","receivedAt":"2008-08-28T05:43:52Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Aug 27, 2008 at 04:38:13PM -0400, Jeff Garzik wrote:\n> Jeff King wrote:\n>> On Wed, Aug 27, 2008 at 04:24:19PM -0400, Jeff Garzik wrote:\n>>\n>>> Indeed.\n>>>\n>>> Also, I type \"git-diff-tree\" quite a lot.\n>>>\n>>> My fingers find that\n>>>\n>>> \tgit SPACE diff DASH tree\n>>>\n>>> is slower and less consistent than\n>>>\n>>> \tgit DASH diff DASH tree\n>>>\n>>> The same with git-format-patch... We are going from \"all dashes\" to \n>>> \"a mix of space and dashes\" which is increasing inconsistency.\n>>\n>> I have also found the SPACE-DASH slightly harder to type. However, I'm\n>> curious: what are you doing frequently from the commandline with\n>> git-diff-tree that is not just as easily done with git-diff?\n>\n> I use it to spit out a patch for a specific commit:\n>\n> \tgit-diff-tree -p $COMMIT\n>\n> Though probably someone will now come along and tell me I'm am \n> old-timer, and there is a shorter command that accomplishes the same \n> thing :)\n\nOther than why you use git diff-tree so much, why don't you set 2\nletters aliases for your most commonly used commands ?\n[alias]\n st = status\n co = checkout\n fp = format-patch\n dt = diff-tree\netc.\n\nMike\n"},{"id":"88979","messageId":"20080828065124.GB16186@elte.hu","threadId":"15184","inReplyTo":"48B5E822.1020901@pobox.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2008-08-28T06:51:24Z","receivedAt":"2008-08-28T06:51:24Z","isPatch":false,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Jeff Garzik wrote:\n\n> > Yeah, the \"much nicer\" obviously does mean \"different\". If you \n> > _rely_ on the fact that you don't get a pager (you just want to \n> > scroll youself), or you really don't want to see what the commit \n> > message was all about, then 'git diff-tree' is obviously \"better\".\n> \n> 'git show' is quite sufficient, as long as I can pipe its output into \n> patch(1) or write it to a foo.patch file, which appears to be the \n> case.\n\nthe only time git show is not sufficient for me in practice, the \nfollowing one is:\n\n git log --pretty=email -p -1\n\nthat's when i want to do precise import/export of patches from/to email. \n(but it's rare)\n\n\tIngo\n"},{"id":"88985","messageId":"1219907659.7107.230.camel@pmac.infradead.org","threadId":"15184","inReplyTo":"7v63pmkozh.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-08-28T07:14:19Z","receivedAt":"2008-08-28T07:14:19Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Wed, 2008-08-27 at 16:38 -0700, Junio C Hamano wrote:\n> The discussion in this thread was about how to go forward from here, now\n> the transition is over. One of the future directions the transition was\n> aiming at was removal of git-foo form for built-ins even from the libexec\n> area -- I was complaining about David's beating an offtopic dead horse in\n> the above, because it was throwing the thread in an off-track direction,\n> distracting everybody from discussing what was more important, discussing\n> constructively if/how to proceed from here.\n\nI'm sorry you feel that way. The reason I didn't object back then was\nalmost certainly because I didn't notice the discussion. I open the git\nmailing list folder so infrequently I might as well not be subscribed. \n\nBut even if I _had_ seen the discussion, I might not have replied.\nLife's too short to undertake a reasoned critique of every crack-addled\n'plan' you see on the Internet. I'm not going to bother arguing with the\nnext person who asserts that we should turn Linux into a microkernel and\nwrite it in C++, and I would have treated some idiotic plan to break git\nin this way with just the same level of interest.\n\n> Now the primary topic of what to do about built-ins have already settled.\n> We _will_ keep git-foo commands in the libexec area. We won't be removing\n> them.\n\nExcellent. All we need to do is make sure the distributions all set\n$(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you\nalso fix it on master.kernel.org please?\n\nI believe we currently have to override $(gitexecdir) at make time --\ncould we have it as an option to ./configure, please?\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"88987","messageId":"20080828074634.GA2862@isilmar.linta.de","threadId":"15184","inReplyTo":"20080828065124.GB16186@elte.hu","subject":"git-show vs git-log (or: git show vs git log)","fromName":"Dominik Brodowski","fromEmail":"linux@dominikbrodowski.net","sentAt":"2008-08-28T07:46:34Z","receivedAt":"2008-08-28T07:46:34Z","isPatch":false,"sender":{"key":"linux@dominikbrodowski.net","avatar":null},"body":"On Thu, Aug 28, 2008 at 08:51:24AM +0200, Ingo Molnar wrote:\n> > 'git show' is quite sufficient, as long as I can pipe its output into \n> > patch(1) or write it to a foo.patch file, which appears to be the \n> > case.\n> \n> the only time git show is not sufficient for me in practice, the \n> following one is:\n> \n> git log --pretty=email -p -1\n> \n> that's when i want to do precise import/export of patches from/to email. \n> (but it's rare)\n\ngit show --pretty=email\n\nBest,\n\tDominik\n"},{"id":"88989","messageId":"7vtzd5fta0.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"1219907659.7107.230.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-28T08:17:11Z","receivedAt":"2008-08-28T08:17:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Woodhouse writes:\n\n> Excellent. All we need to do is make sure the distributions all set\n> $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you\n> also fix it on master.kernel.org please?\n\nAre you trying to irritate me even more?\n\nAlthough I personally did not particularly like the \"out of /usr/bin\" move,\nthis was done by user request. I now am hated for doing something I was\ndragged into doing, not because I wanted the change, but only because many\nothers wanted it, and you are dreaming that another pointless change will\nbe made in the other direction?\n\nGet a clue already.\n"},{"id":"88991","messageId":"1219912327.7107.245.camel@pmac.infradead.org","threadId":"15184","inReplyTo":"7vtzd5fta0.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-08-28T08:32:07Z","receivedAt":"2008-08-28T08:32:07Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote:\n> David Woodhouse writes:\n> \n> > Excellent. All we need to do is make sure the distributions all set\n> > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you\n> > also fix it on master.kernel.org please?\n> \n> Are you trying to irritate me even more?\n\nNot at all; I'm sorry if that's the effect.\n\n> Although I personally did not particularly like the \"out of /usr/bin\" move,\n> this was done by user request. I now am hated for doing something I was\n> dragged into doing, not because I wanted the change, but only because many\n> others wanted it, and you are dreaming that another pointless change will\n> be made in the other direction?\n\nI'm not asking you to make another change in upstream git. You've told\nus the workaround (gitexecdir=/usr/bin), and that workaround is no\nlonger going to be deprecated, which is great. It's just up to us to\nensure that we use that workaround when we build git for ourselves, and\nto ensure that our distributions also build packages using that\nworkaround.\n\nSince I believe you're building the git packages used on kernel.org, I\nwas just asking you to apply the workaround when you build _those_\npackages, that's all.\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"88995","messageId":"94a0d4530808280157p230d289dlf0c85cd517541801@mail.gmail.com","threadId":"15184","inReplyTo":"1219912327.7107.245.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-28T08:57:56Z","receivedAt":"2008-08-28T08:57:56Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 28, 2008 at 11:32 AM, David Woodhouse wrote:\n> On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote:\n>> David Woodhouse writes:\n>>\n>> > Excellent. All we need to do is make sure the distributions all set\n>> > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you\n>> > also fix it on master.kernel.org please?\n>>\n>> Are you trying to irritate me even more?\n>\n> Not at all; I'm sorry if that's the effect.\n>\n>> Although I personally did not particularly like the \"out of /usr/bin\" move,\n>> this was done by user request. I now am hated for doing something I was\n>> dragged into doing, not because I wanted the change, but only because many\n>> others wanted it, and you are dreaming that another pointless change will\n>> be made in the other direction?\n>\n> I'm not asking you to make another change in upstream git. You've told\n> us the workaround (gitexecdir=/usr/bin), and that workaround is no\n> longer going to be deprecated, which is great. It's just up to us to\n> ensure that we use that workaround when we build git for ourselves, and\n> to ensure that our distributions also build packages using that\n> workaround.\n>\n> Since I believe you're building the git packages used on kernel.org, I\n> was just asking you to apply the workaround when you build _those_\n> packages, that's all.\n\nYou are getting it wrong.\n\nIf *you* want the git-foo form, then *you* add the git exec dir to your PATH.\n\nThe masses should forget about the git-foo form. If you push people\ninto using git-foo then you are not following git guidelines; you\nwould be pushing your own agenda.\n\n-- \nFelipe Contreras\n"},{"id":"88997","messageId":"20080828090421.GQ10360@machine.or.cz","threadId":"15184","inReplyTo":"BD6DEBB7-4D1C-43E9-B3D2-B46E42D9771D@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-28T09:04:21Z","receivedAt":"2008-08-28T09:04:21Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" This thread is starting to seriously irritate even *me* by now, which\nis quite a feat...\n\nOn Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote:\n> Oh yeah, sorry. I neglected to mention that my problem was having the \n> git- forms in scripts all over an internal network, and having no \n> amazingly easy way of fixing them. I don't know who all copied them.\n\n Should I count for you how many times the $PATH workaround has been\nmentioned already? Or the gitexecdir workaround?\n\n> On Aug 27, 2008, at 4:53 PM, Perry Wagle wrote:\n> \n> >\n> > On Aug 27, 2008, at 4:27 PM, Junio C Hamano wrote:\n> >\n> >> Steven Rostedt writes:\n> >>\n> >>> Yes, they are all a bunch of Nazi git fanatics, that Hitler \n> >>> himself would\n> >>> have used the space version of git. He sent the Jews off to the\n> >>> concentration camps because they insisted on using the dashes.\n> >>>\n> >>> There, we have a Hitler reference.\n> >>>\n> >>> CAN WE PLEASE LET THIS THREAD DIE!\n\n Intentional invocations of Godwin's Law don't count - sadly. ;-)\n\n> > I suggested that git used to give the same 143 \n> > completions that git would now. This meant that making \n> > any arguments that the number was off-putting to newbies did not \n> > apply, since you had a same number (143) either way. Putting stuff \n> > in libexec does not change the above observation in any fashion.\n> >\n> > A response to my observation was that \"not everything will show up \n> > in the latter completion\". I balked at that as it distorted the \n> > truth. If this distortion would actually take place then I have a \n> > real complaint. Not a tangent.\n> >\n> > But as long as git does the *same* thing as \n> > git, I really do not see why you had to go break my \n> > scripts on a *minor* revision for what amounts to no reason as all.\n\n What the hell are you talking about? Did you *try*? git\ndoes not do the same thing as git, and it has been clearly\nstated in this thread several times. It shows only the commands that are\n*interesting* for the user, just as $PATH does not include /usr/sbin and\n/sbin and /usr/lib/wine because the executables in these directories\njust aren't interesting for the users. If you care about all the Git\ninternals, go read git(1) to see the list of all the plumbing stuff.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"89001","messageId":"18219E52-E56F-43D9-B28D-0CC74E225CC5@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828090421.GQ10360@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T10:33:46Z","receivedAt":"2008-08-28T10:33:46Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"On Aug 28, 2008, at 2:04 AM, Petr Baudis wrote:\n\n> This thread is starting to seriously irritate even *me* by now, which\n> is quite a feat...\n>\n> On Wed, Aug 27, 2008 at 05:05:33PM -0700, Perry Wagle wrote:\n>> Oh yeah, sorry. I neglected to mention that my problem was having \n>> the\n>> git- forms in scripts all over an internal network, and having no\n>> amazingly easy way of fixing them. I don't know who all copied them.\n>\n> Should I count for you how many times the $PATH workaround has been\n> mentioned already? Or the gitexecdir workaround?\n\nThe PATH thing fixes the problem of typing in git-commands at the \ncommand line, but not for scripts containing git commands. I've \nseen no-one rebut my rebuttal.\n\nAre you suggesting that I break into machines that I don't have access \nto add a export PATH= line to copies of scripts that were written 6 \nmonths ago, and worked just fine until someone decided that \"upward \ncompatibility\" wasn't an important concept?\n\nWhat other upward compatibilities were broken in the past six months? \nWhat am I testing for tomorrow when I fix it before releasing an \nupgraded git? Next month?\n\nI really don't understand this \"upward compatibility doesn't matter\" \nthing.\n\n> What the hell are you talking about? Did you *try*? git\n> does not do the same thing as git, and it has been clearly\n> stated in this thread several times. It shows only the commands that \n> are\n> *interesting* for the user, just as $PATH does not include /usr/sbin \n> and\n> /sbin and /usr/lib/wine because the executables in these directories\n> just aren't interesting for the users. If you care about all the Git\n> internals, go read git(1) to see the list of all the plumbing stuff.\n\nIn this thread the new completion thing has been clearly stated both \nways.\n\nI have one, apparently very authoritative, response in this thread \nassuring me that it will not be the case that the command completion \nspace will be restricted in the fashion you support. I'm not sure who \nto believe. It might not matter: apparently, one person in the thread \nwas forced to make the change we are all responding to here. When \ndoes that happen again?\n\nI find the notion that the command completion should give partial \nresults an unpleasant concept. I've been stuck with systems with no \ndocumentation, but with command completion with that sort of thinking, \nand as a result, and it was very frustrating.\n\n-- Perry\n"},{"id":"89002","messageId":"1219920145.7107.273.camel@pmac.infradead.org","threadId":"15184","inReplyTo":"18219E52-E56F-43D9-B28D-0CC74E225CC5@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2008-08-28T10:42:25Z","receivedAt":"2008-08-28T10:42:25Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote:\n> Are you suggesting that I break into machines that I don't have access\n> to add a export PATH= line to copies of scripts that were written 6 \n> months ago, and worked just fine until someone decided that \"upward \n> compatibility\" wasn't an important concept?\n\nNot at all. But as long as you also refrain from breaking into those\nsame machines and upgrading them to git 1.6.0, you should be fine.\n\nOr if you _do_ upgrade them to git 1.6.0, you should make sure you build\nwith gitexecdir=/usr/bin to prevent the breakage.\n\nWhat distribution are you running on those machines? If they upgrade\ntheir version of git from an earlier version to 1.6.0 in a stable\nrelease without setting gitexecdir=/usr/bin to preserve compatibility,\nthen the packager needs to be taken out back and shot.\n\nPerhaps you should file a bug in advance, to make sure they're aware of\nthe issue and make sure that if/when they update to 1.6.0, they set\ngitexecdir properly.\n\n-- \nDavid Woodhouse Open Source Technology Centre\nDavid.Woodhouse@intel.com Intel Corporation\n"},{"id":"89003","messageId":"20080828104756.GR10360@machine.or.cz","threadId":"15184","inReplyTo":"18219E52-E56F-43D9-B28D-0CC74E225CC5@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-28T10:47:56Z","receivedAt":"2008-08-28T10:47:56Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"I'm removing users@kernel.org from the Cc list since this is far beyond\nrelevant there.\n\nOn Thu, Aug 28, 2008 at 03:33:46AM -0700, Perry Wagle wrote:\n> The PATH thing fixes the problem of typing in git-commands at the command \n> line, but not for scripts containing git commands. I've seen no-one \n> rebut my rebuttal.\n\nHuh? $PATH takes effect both on command-line and in scripts. Maybe you\nwanted to phrase this paragraph differently.\n\n> Are you suggesting that I break into machines that I don't have access to \n> add a export PATH= line to copies of scripts that were written 6 months \n> ago, and worked just fine until someone decided that \"upward compatibility\" \n> wasn't an important concept?\n\nNo, they worked just fine until someone upgraded Git there. That\n$someone needs to take care of this.\n\n> What other upward compatibilities were broken in the past six months? What \n> am I testing for tomorrow when I fix it before releasing an upgraded git? \n> Next month?\n>\n> I really don't understand this \"upward compatibility doesn't matter\" thing.\n\nThe deprecation has been announced several times. Yes, we might've done\nbetter job spreading the word and the documentation still needs updates;\nfrom that it's apparent we're lacking at resources here and help is\nwelcome. Ask your money back or send patches.\n\n> In this thread the new completion thing has been clearly stated both ways.\n>\n> I have one, apparently very authoritative, response in this thread assuring \n> me that it will not be the case that the command completion space will be \n> restricted in the fashion you support. I'm not sure who to believe. It \n> might not matter: apparently, one person in the thread was forced to make \n> the change we are all responding to here. When does that happen again?\n\nWhat response is that? I can see only Andi Kleen's post, and it didn't\nactually even directly claim that this is the current behaviour. Then\nthere's bunch of posts showing that it's not the case. Well, I can only\nshrug my shoulders.\n\nSince after all, you clearly just feel like flaming and don't actually\n_care_ about this issue at all since you would just _try_ it out if this\nactually mattered to you.\n\n> I find the notion that the command completion should give partial results \n> an unpleasant concept. I've been stuck with systems with no documentation, \n> but with command completion with that sort of thinking, and as a result, \n> and it was very frustrating.\n\nGit has documentation.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"88872","messageId":"20080828115408.GA30834@hera.kernel.org","threadId":"15184","inReplyTo":"94a0d4530808280157p230d289dlf0c85cd517541801@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Al Viro","fromEmail":"viro@hera.kernel.org","sentAt":"2008-08-28T11:54:08Z","receivedAt":"2008-08-28T11:54:08Z","isPatch":false,"sender":{"key":"viro@hera.kernel.org","avatar":null},"body":"On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:\n\n> The masses should forget about the git-foo form. If you push people\n> into using git-foo then you are not following git guidelines; you\n> would be pushing your own agenda.\n\nEgads... For sarcasm it's far too heavy-handed and if that's for real...\nWhat's next, verbal diarrhea about Diluting the Message(tm)?\n"},{"id":"88882","messageId":"94a0d4530808280615i2befb89cm7d6153bfceb11b19@mail.gmail.com","threadId":"15184","inReplyTo":"20080828115408.GA30834@hera.kernel.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-28T13:15:08Z","receivedAt":"2008-08-28T13:15:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 28, 2008 at 2:54 PM, Al Viro wrote:\n> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:\n>\n>> The masses should forget about the git-foo form. If you push people\n>> into using git-foo then you are not following git guidelines; you\n>> would be pushing your own agenda.\n>\n> Egads... For sarcasm it's far too heavy-handed and if that's for real...\n> What's next, verbal diarrhea about Diluting the Message(tm)?\n\nSorry, I guess I should have made it clearer.\n\nI haven't made my mind about git-foo vs \"git foo\", but a decision has\nbeen made to deprecate git-foo, and allow it as an option for the\npeople that really want to use it, right?\n\nSo there must have been a reason to deprecate git-foo, if people keep\nusing git-foo, and distributions keep allowing it, what's the point of\ndeprecation? It's ok if they keep that usage to themselves, like\n'alias ll = ls -l', but it's not something to assume everybody uses.\n\nSo either we take back the decision and keep discussing if it's a good\nidea to deprecate git-foo, or we go forward and discourage git-foo\ncompletely.\n\nAnything in the middle would just confuse people more, and wouldn't\nachieve the purpose of deprecation.\n\nIf some script is relying on git-foo, and it has been deprecated, it\nshould be fixed.\n\nBest regards.\n\n-- \nFelipe Contreras\n"},{"id":"88884","messageId":"94a0d4530808280634k1c23fe10q8934875c83d4a2f5@mail.gmail.com","threadId":"15184","inReplyTo":"94a0d4530808280615i2befb89cm7d6153bfceb11b19@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-28T13:34:08Z","receivedAt":"2008-08-28T13:34:08Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras\n wrote:\n> On Thu, Aug 28, 2008 at 2:54 PM, Al Viro wrote:\n>> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:\n>>\n>>> The masses should forget about the git-foo form. If you push people\n>>> into using git-foo then you are not following git guidelines; you\n>>> would be pushing your own agenda.\n>>\n>> Egads... For sarcasm it's far too heavy-handed and if that's for real...\n>> What's next, verbal diarrhea about Diluting the Message(tm)?\n>\n> Sorry, I guess I should have made it clearer.\n>\n> I haven't made my mind about git-foo vs \"git foo\", but a decision has\n> been made to deprecate git-foo, and allow it as an option for the\n> people that really want to use it, right?\n>\n> So there must have been a reason to deprecate git-foo, if people keep\n> using git-foo, and distributions keep allowing it, what's the point of\n> deprecation? It's ok if they keep that usage to themselves, like\n> 'alias ll = ls -l', but it's not something to assume everybody uses.\n>\n> So either we take back the decision and keep discussing if it's a good\n> idea to deprecate git-foo, or we go forward and discourage git-foo\n> completely.\n>\n> Anything in the middle would just confuse people more, and wouldn't\n> achieve the purpose of deprecation.\n>\n> If some script is relying on git-foo, and it has been deprecated, it\n> should be fixed.\n\nActually, now I think I understand the point of David Woodhouse better.\n\nIf the git-foo was supposed to be deprecated in 1.6.0, it should still\nwork by default, but something to strongly discourage it like a\nwarning should have been added.\n\nWhen it becomes truly obsolete, then people can rely on git exec-dir,\nwhich will be disabled by default.\n\nSo is it deprecated or obsolete?\n\n-- \nFelipe Contreras\n"},{"id":"88886","messageId":"4d8e3fd30808280645n95b0afat1e9ed2e79a38498f@mail.gmail.com","threadId":"15184","inReplyTo":"94a0d4530808280634k1c23fe10q8934875c83d4a2f5@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2008-08-28T13:45:56Z","receivedAt":"2008-08-28T13:45:56Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On Thu, Aug 28, 2008 at 3:34 PM, Felipe Contreras\n wrote:\n> On Thu, Aug 28, 2008 at 4:15 PM, Felipe Contreras\n> wrote:\n>> On Thu, Aug 28, 2008 at 2:54 PM, Al Viro wrote:\n>>> On Thu, Aug 28, 2008 at 11:57:56AM +0300, Felipe Contreras wrote:\n>>>\n>>>> The masses should forget about the git-foo form. If you push people\n>>>> into using git-foo then you are not following git guidelines; you\n>>>> would be pushing your own agenda.\n>>>\n>>> Egads... For sarcasm it's far too heavy-handed and if that's for real...\n>>> What's next, verbal diarrhea about Diluting the Message(tm)?\n>>\n>> Sorry, I guess I should have made it clearer.\n>>\n>> I haven't made my mind about git-foo vs \"git foo\", but a decision has\n>> been made to deprecate git-foo, and allow it as an option for the\n>> people that really want to use it, right?\n>>\n>> So there must have been a reason to deprecate git-foo, if people keep\n>> using git-foo, and distributions keep allowing it, what's the point of\n>> deprecation? It's ok if they keep that usage to themselves, like\n>> 'alias ll = ls -l', but it's not something to assume everybody uses.\n>>\n>> So either we take back the decision and keep discussing if it's a good\n>> idea to deprecate git-foo, or we go forward and discourage git-foo\n>> completely.\n>>\n>> Anything in the middle would just confuse people more, and wouldn't\n>> achieve the purpose of deprecation.\n>>\n>> If some script is relying on git-foo, and it has been deprecated, it\n>> should be fixed.\n>\n> Actually, now I think I understand the point of David Woodhouse better.\n>\n> If the git-foo was supposed to be deprecated in 1.6.0, it should still\n> work by default, but something to strongly discourage it like a\n> warning should have been added.\n>\n> When it becomes truly obsolete, then people can rely on git exec-dir,\n> which will be disabled by default.\n>\n> So is it deprecated or obsolete?\n\nI quote Junio:\n--8<---\nWe have deprecated the dashed form in early 2006, and announced that 1.6.0\nwill remove them from $PATH in the 1.5.4 release notes, with instructions\non how to update their scripts before 1.6.0 happens. Many people knew\nabout this transition, but they didn't do anything about it. Since 2005,\ngit has matured enough that majority of people are using it without\nbuilding one themselves, without a chance to even read Release Notes\n--8<---\n\nCiao,\n-- \nPaolo\nhttp://paolo.ciarrocchi.googlepages.com/\n"},{"id":"88889","messageId":"alpine.LFD.1.10.0808281002270.1624@xanadu.home","threadId":"15184","inReplyTo":"1219912327.7107.245.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-08-28T14:06:32Z","receivedAt":"2008-08-28T14:06:32Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 28 Aug 2008, David Woodhouse wrote:\n\n> On Thu, 2008-08-28 at 01:17 -0700, Junio C Hamano wrote:\n> > David Woodhouse writes:\n> > \n> > > Excellent. All we need to do is make sure the distributions all set\n> > > $(gitexecdir) to /usr/bin when they upgrade to 1.6.0 -- and could you\n> > > also fix it on master.kernel.org please?\n> > \n> > Are you trying to irritate me even more?\n> \n> Not at all; I'm sorry if that's the effect.\n> \n> > Although I personally did not particularly like the \"out of /usr/bin\" move,\n> > this was done by user request. I now am hated for doing something I was\n> > dragged into doing, not because I wanted the change, but only because many\n> > others wanted it, and you are dreaming that another pointless change will\n> > be made in the other direction?\n> \n> I'm not asking you to make another change in upstream git. You've told\n> us the workaround (gitexecdir=/usr/bin), and that workaround is no\n> longer going to be deprecated, which is great. It's just up to us to\n> ensure that we use that workaround when we build git for ourselves, and\n> to ensure that our distributions also build packages using that\n> workaround.\n\n... effectively denying all those who asked for \"git \" from _easily_ \ngetting it. OTOH, you can _trivially_ add $(git --exec-path) to your \n$PATH and forget about it.\n\n\nNicolas\n"},{"id":"88892","messageId":"alpine.LFD.1.10.0808281011550.1624@xanadu.home","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808281002270.1624@xanadu.home","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-08-28T14:13:54Z","receivedAt":"2008-08-28T14:13:54Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 28 Aug 2008, Nicolas Pitre wrote:\n\n> On Thu, 28 Aug 2008, David Woodhouse wrote:\n> \n> > I'm not asking you to make another change in upstream git. You've told\n> > us the workaround (gitexecdir=/usr/bin), and that workaround is no\n> > longer going to be deprecated, which is great. It's just up to us to\n> > ensure that we use that workaround when we build git for ourselves, and\n> > to ensure that our distributions also build packages using that\n> > workaround.\n> \n> ... effectively denying all those who asked for \"git \" from _easily_ \n> getting it.\n\nBy this I mean \"git-\" out of /usr/bin, before someone replies saying \nthat \"git \" is always available.\n\n\nNicolas\n"},{"id":"88895","messageId":"81b0412b0808280744q7ab0aa9l2064117c4e147351@mail.gmail.com","threadId":"15184","inReplyTo":"20080828065124.GB16186@elte.hu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2008-08-28T14:44:45Z","receivedAt":"2008-08-28T14:44:45Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"2008/8/28 Ingo Molnar :\n> * Jeff Garzik wrote:\n>>\n>> 'git show' is quite sufficient, as long as I can pipe its output into\n>> patch(1) or write it to a foo.patch file, which appears to be the\n>> case.\n>\n> the only time git show is not sufficient for me in practice, the\n> following one is:\n>\n> git log --pretty=email -p -1\n>\n\n\"git show --pretty=email\", indeed 8-)\n\n> that's when i want to do precise import/export of patches from/to email.\n> (but it's rare)\n\nBut it does not export them \"precisely\". You get no patch for\nmerges (even if there were changes). Try using \"git format-patch\n--stdout\" (or with \"-o \" instead of \"--stdout\", to split in\npatches).\n"},{"id":"88899","messageId":"alpine.DEB.1.00.0808281719130.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15184","inReplyTo":"20080826173512.GS10544@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-28T15:21:29Z","receivedAt":"2008-08-28T15:21:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 26 Aug 2008, Petr Baudis wrote:\n\n> On Tue, Aug 26, 2008 at 06:29:03PM +0100, Bruce Stephens wrote:\n> > - it means git on Windows has the same interface\n> > \n> > (Arguably the latter point ought to be \"forces Unix users to use the\n> > same interface as on Windows\", but the git-foo forms have been\n> > deprecated on all platforms for a while. Making Unix and Windows the\n> > same seems a worthwhile goal, though presumably it's irrelevant for\n> > linux kernel people.)\n> \n> I actually checked, and my msysgit installation does hardlinking (or at\n> least pretends to do, and ls -l shows high linkcounts). And somewhat\n> amusingly, it doesn't appear that 1.6.0 will be released for Windows\n> anytime soon, though that's of course not relevant from long term\n> perspective.\n\nThat is correct. Even more amusingly, it cannot be released ATM because \nof a breakage _caused_ by the move into libexec: on Windows, we _want_ to \nbe as relocatable as possible, i.e. not having an _absolute_ exec path \ncompiled in. So we use a relative one. And that's the rub: from bin/ \n(for \"git\") and from libexec/git/ (for almost all others), there is no \nsingle relative path to etc/.\n\nFunny, eh?\nDscho\n"},{"id":"88901","messageId":"alpine.DEB.1.00.0808281723580.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15184","inReplyTo":"20080826185548.GA7559@hera.kernel.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-28T15:24:46Z","receivedAt":"2008-08-28T15:24:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 26 Aug 2008, Al Viro wrote:\n\n> Well, to be fair, \"man git-add for git add is rather unconventional\" is \n> a valid point...\n\nIf you're prepared for even more whining, you could send a patch that \ninlines all git commands into Documentation/git.txt...\n\nDucks,\nDscho\n"},{"id":"88903","messageId":"alpine.DEB.1.00.0808281731490.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808261717480.1624@xanadu.home","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-28T15:32:23Z","receivedAt":"2008-08-28T15:32:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 26 Aug 2008, Nicolas Pitre wrote:\n\n> On Tue, 26 Aug 2008, Junio C Hamano wrote:\n> \n> > Read the subject line again, and notice that we are not talking about\n> > /usr/bin vs /usr/libexec/git-core; the request-for-discussion was about\n> > removing \"git-add\" and friends from /usr/libexec/git-core/, so that we do\n> > not have to even have these many hardlinks there. Except for Linus (and\n> > obviously myself who started the thread), I saw nobody expressed any\n> > opinion on it.\n> \n> Don't deprecate git-foo and leave them in $gitexecdir as things are now.\n> That's the best compromise IMHO.\n> \n> Those who want git-foo can have it via several and easy means. Those \n> who want 'git foo' have it by default which IMHO is pretty sane (the \n> other way around is less easy so 'git foo' being the default is the most \n> sensible alternative).\n> \n> Platforms where filesystem links are not available simply don't have to \n> support the git-foo form, period. I doubt users of such platforms will \n> care much.\n> \n> All the rest is only bikeshedding.\n\nNot wanting to be part of a _silent_ majority, I fully agree, loudly.\n\nCiao,\nDscho\n"},{"id":"88908","messageId":"alpine.DEB.1.00.0808281733460.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15184","inReplyTo":"20080827225233.GA11005@flint.arm.linux.org.uk","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-28T15:34:43Z","receivedAt":"2008-08-28T15:34:43Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 27 Aug 2008, Russell King wrote:\n\n> On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:\n> > On Tue, Aug 26, 2008 at 01:39:30PM -0700, Junio C Hamano wrote:\n> > > When I hear something like what David Woodhouse said in this thread, I\n> > > should be feeling \"People -- those of you who claimed to be the silent\n> > > majority -- see, I told you so! This is a very bad move\".\n> > > \n> > > But I can't. People who complain _now_ just annoy me even more. Why\n> > > weren't you defending the backward compatibility with me, which you seem\n> > > to value it so much, perhaps even more than I did back then? Why are you\n> > > wasting our time bringing it up again, instead of joining the discussion\n> > > when it _mattered_ back then?\n> > \n> > We didn't know the conversation was going on. Why should we? We only\n> > use the tool, not develop it. I'm also not on the mailing lists for\n> > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\n> > any of the dozens of other programs I use on a daily basis.\n> \n> Well said Matthew, as a git _user_ I completely agree.\n\nSo are you effectively saying that we should have asked on all the mailing \nlist of existing and potential Git users to ask their opinions?\n\nGiggling,\nDscho\n"},{"id":"88911","messageId":"20080828161040.GH18340@parisc-linux.org","threadId":"15184","inReplyTo":"alpine.DEB.1.00.0808281733460.24820@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthew Wilcox","fromEmail":"matthew@wil.cx","sentAt":"2008-08-28T16:10:40Z","receivedAt":"2008-08-28T16:10:40Z","isPatch":false,"sender":{"key":"matthew@wil.cx","avatar":null},"body":"On Thu, Aug 28, 2008 at 05:34:43PM +0200, Johannes Schindelin wrote:\n> On Wed, 27 Aug 2008, Russell King wrote:\n> > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:\n> > > We didn't know the conversation was going on. Why should we? We only\n> > > use the tool, not develop it. I'm also not on the mailing lists for\n> > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\n> > > any of the dozens of other programs I use on a daily basis.\n> > \n> > Well said Matthew, as a git _user_ I completely agree.\n> \n> So are you effectively saying that we should have asked on all the mailing \n> list of existing and potential Git users to ask their opinions?\n\nNo. I'm effectively saying that *you shouldn't break backwards\ncompatibility*. Ever. It only annoys people.\n\nIncluding:\n - The maintainer who has to listen to all this whining\n - Everyone who gets this thread cc'd in their inbox\n - People who hadn't been informed of the new way of doing things\n - People who thought they'd got their own way and now have to suffer\n the 'silent majority' speaking up.\n - Linus\n\n-- \nMatthew Wilcox\t\t\t\tIntel Open Source Technology Centre\n\"Bill, look, we understand that you're interested in selling us this\noperating system, but compare it to ours. We can't possibly take such\na retrograde step.\"\n"},{"id":"88912","messageId":"alpine.LFD.1.10.0808280912510.3300@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"1219912327.7107.245.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-28T16:17:39Z","receivedAt":"2008-08-28T16:17:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Aug 2008, David Woodhouse wrote:\n> \n> I'm not asking you to make another change in upstream git. You've told\n> us the workaround (gitexecdir=/usr/bin)\n\nNo.\n\nThat's your _personal_ workaround.\n\nOthers DO NOT WANT IT.\n\nI, for example, no longer want git-xyzzy in my path.\n\nSo the real workaround is \n\n - you compile YOUR OWN VERSION instead of trying to force your stupid \n opinion on everybody by forcing the default for distros to be \n _idiotic_, and then you can do that gitexecdir=/usr/bin and wallow in \n your own shitty inability to teach yourself not to do the dash.\n\n - or you do - in a _personal_ file - that\n\n\tPATH=\"$PATH:$(git --exec-path)\"\n\n thing, and forget about it, and never ever have to worry about how git \n was compiled and installed.\n\nThe second is obviously the much superior model, exactly because it allows \nthose people who do _not_ want to see git-xyzzy to work on the same \nmachine.\n\n> Since I believe you're building the git packages used on kernel.org, I\n> was just asking you to apply the workaround when you build _those_\n> packages, that's all.\n\nDon't be silly. Why are you grand poo-bah? Why cannot you just add your \nPATH to your .bash_profile?\n\nGet over it already. Why the hell are you _still_ whining, after I have \ntold you to do that PATH thing at least ten times already?\n\n\t\tLinus\n"},{"id":"88914","messageId":"alpine.LFD.1.10.0808280934160.3300@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"18219E52-E56F-43D9-B28D-0CC74E225CC5@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-28T16:35:16Z","receivedAt":"2008-08-28T16:35:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Aug 2008, Perry Wagle wrote:\n> \n> The PATH thing fixes the problem of typing in git-commands at the \n> command line, but not for scripts containing git commands. I've \n> seen no-one rebut my rebuttal.\n\nWhat drugs are you people on?\n\nJust put it in your .bash_profile or something. It will now work for all \nyour scripts.\n\nAnd for us people who do _not_ want it, we fix the scripts, or we don't \nrun them.\n\n\t\tLinus\n"},{"id":"88913","messageId":"alpine.LFD.1.10.0808280936300.3300@nehalem.linux-foundation.org","threadId":"15184","inReplyTo":"94a0d4530808280634k1c23fe10q8934875c83d4a2f5@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2008-08-28T16:37:20Z","receivedAt":"2008-08-28T16:37:20Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Aug 2008, Felipe Contreras wrote:\n> \n> If the git-foo was supposed to be deprecated in 1.6.0\n\nItw as deprecated over a _year_ ago.\n\n> When it becomes truly obsolete, then people can rely on git exec-dir,\n> which will be disabled by default.\n\nIt _is_ obsolete, but there's a trivial compatibility thing.\n\nAre you happy now? How hard is it to really understand?\n\n\t\tLinus\n"},{"id":"88949","messageId":"alpine.DEB.1.00.0808282113410.24820@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15184","inReplyTo":"20080828161040.GH18340@parisc-linux.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-08-28T19:18:53Z","receivedAt":"2008-08-28T19:18:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 28 Aug 2008, Matthew Wilcox wrote:\n\n> On Thu, Aug 28, 2008 at 05:34:43PM +0200, Johannes Schindelin wrote:\n> > On Wed, 27 Aug 2008, Russell King wrote:\n> > > On Tue, Aug 26, 2008 at 06:17:05PM -0600, Matthew Wilcox wrote:\n> > > > We didn't know the conversation was going on. Why should we? We only\n> > > > use the tool, not develop it. I'm also not on the mailing lists for\n> > > > mutt, vim, gcc, binutils, openssh, grep, xchat, mozilla, gnome, xpdf or\n> > > > any of the dozens of other programs I use on a daily basis.\n> > > \n> > > Well said Matthew, as a git _user_ I completely agree.\n> > \n> > So are you effectively saying that we should have asked on all the mailing \n> > list of existing and potential Git users to ask their opinions?\n> \n> No. I'm effectively saying that *you shouldn't break backwards\n> compatibility*. Ever. It only annoys people.\n\nThis is something that comes out of a male cow, and from his back exit.\n\nYou are saying that something that was deprecated loooong time ago should \nbe kept for backwards compatibility reasons. That cannot hold, and you \nknow that.\n\nAnyway, you even failed to address my complaint, namely that Russell did \nnot give us a _chance_. He did not read the mailing list on which the \nissue was discussed -- and again, it is not a compatibility issue. But he \nwanted to be notified. Like they say, you cannot have your cake and eat \nit, too.\n\nAs to everybody who still wants to complain that git-xyyx is so much \nbetter than \"git xyyx\": face it, it's the better solution for almost \neverybody except for you. Cope with it.\n\nOh, and I am sorry if it broke your scripts, but they are easy to fix. I \nknow, because I had to fix mine, too.\n\nCiao,\nDscho\n"},{"id":"88954","messageId":"20080828191956.GA7906@flint.arm.linux.org.uk","threadId":"15184","inReplyTo":"48B5E90E.3000601@s5r6.in-berlin.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2008-08-28T19:19:56Z","receivedAt":"2008-08-28T19:19:56Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:\n> Russell King wrote:\n> >And no warnings before hand that the commands you were using were\n> >deprecated.\n> \n> (a) They weren't deprecated, they were moved into a different directory.\n\nI think Junio will tell you differently on the \"deprecation\" bit.\n\n> (b) There have been several announcements of the 1.6.0 prereleases and \n> the 1.6.0 release crossposted. Of course somebody forgot to tell you \n> what you will learn from these release notes. Unfair.\n\nCross posting to high traffic mailing lists doesn't guarantee that\nit'll be read. It's the wrong place to do it.\n\nArguably, though, the lack of information to users on the system affected\nis not git maintainers fault. It's the fault of the admins on that system\nnot having read the release notes themselves, and warning their users (for\nwhom git is a *critical* bit of software) that an upgrade is going to take\nplace, and they should read such-and-such.\n\nLike a note in the system MOTD.\n\n> (c) There do happen unannounced software updates on shell servers over \n> which you don't have control. Ask for your money back.\n> \n> (d) \"-\" -> \" \"? Molehill.\n\n\"ls\" -> \"listfiles\" - how would you feel about that change happening\nbehind your back?\n\n-- \nRussell King\n Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/\n maintainer of:\n"},{"id":"88953","messageId":"7BC51BEC-E230-48C5-BD3E-2CECE3C7FC98@cs.indiana.edu","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808280934160.3300@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T19:24:17Z","receivedAt":"2008-08-28T19:24:17Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"On Aug 28, 2008, at 9:35 AM, Linus Torvalds wrote:\n\n> On Thu, 28 Aug 2008, Perry Wagle wrote:\n>>\n>> The PATH thing fixes the problem of typing in git-commands at the\n>> command line, but not for scripts containing git commands. \n>> I've\n>> seen no-one rebut my rebuttal.\n>\n> What drugs are you people on?\n\nNo drugs, just that I was expecting people to do more than demonstrate \nto me the excellence of their knee reflex. Especially you (Linus), \nwho supports thinking things out and not depending on debugging tools.\n\nI prefer to think things out and not \"coding from the hip\". I can be \nproven wrong, but you are going to have to engage your brain to do \nso. Threatening me or whacking me with the neural loop from your \nspine to your knee isn't going to cut it.\n\n> Just put it in your .bash_profile or something. It will now work for \n> all\n> your scripts.\n\nIn terms of continuing to provide me git if I so desire, \nthat's an excellent idea, and I've repeatedly said so.\n\nIn terms of preserving scripts, thats a filthy hack that only fixes my \nown execution of those scripts, not for other people. And some people \ndon't run bash, so /etc/bashrc *on every system* or whatever doesn't \nactually do it either. Did you think that out?\n\n> And for us people who do _not_ want it, we fix the scripts, or we \n> don't\n> run them.\n\nThis is one upward compatibility broken for goofy reasons, at least \nthose given in this thread, where there were numerous \"ZOMG! I get \n143 completions!\" accompanied by false claims that it was a 143 \nelement *list* when in fact a *hash table* is used.\n\nBut the issue for me is what other upward compatibilities were \nbroken? What am I testing for? Is is really only that I\n\n sed s/git-/git/g\n\non the scripts? I'm doubting it, given the quality of reasoning and \nlack of respect for upward compatibility on this thread.\n\nYes, I'm over-killing a molehill, but I see you all building a \nmountain in the distance that I don't feel like climbing. I haven't \nbeen paid to do git stuff for months.\n\n-- Perry\n"},{"id":"88955","messageId":"20080828192737.GN18340@parisc-linux.org","threadId":"15184","inReplyTo":"alpine.DEB.1.00.0808282113410.24820@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthew Wilcox","fromEmail":"matthew@wil.cx","sentAt":"2008-08-28T19:27:38Z","receivedAt":"2008-08-28T19:27:38Z","isPatch":false,"sender":{"key":"matthew@wil.cx","avatar":null},"body":"On Thu, Aug 28, 2008 at 09:18:53PM +0200, Johannes Schindelin wrote:\n> > No. I'm effectively saying that *you shouldn't break backwards\n> > compatibility*. Ever. It only annoys people.\n> \n> This is something that comes out of a male cow, and from his back exit.\n\nOK, I'm done.\n\n-- \nMatthew Wilcox\t\t\t\tIntel Open Source Technology Centre\n\"Bill, look, we understand that you're interested in selling us this\noperating system, but compare it to ours. We can't possibly take such\na retrograde step.\"\n"},{"id":"88957","messageId":"20080828195211.GA3545@mithlond.arda.local","threadId":"15184","inReplyTo":"7BC51BEC-E230-48C5-BD3E-2CECE3C7FC98@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-08-28T19:52:11Z","receivedAt":"2008-08-28T19:52:11Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Perry Wagle wrote (2008-08-28 12:24 -0700):\n\n> Is is really only that I\n> \n> sed s/git-/git/g\n> \n> on the scripts? I'm doubting it, given the quality of reasoning and\n> lack of respect for upward compatibility on this thread.\n\nI have come to understand that \"git \" has quite long time been more \nrobust and portable way of writing scripts. They work in both \nconfigurations so I'd definitely suggest doing \"s/git-/git /g\" for every \nscript. Of course in an interactive shell everyone can use whatever they \nprefer and works at the moment.\n"},{"id":"88959","messageId":"EEE40F07-E371-45A1-ADB0-E6B680B2555F@cs.indiana.edu","threadId":"15184","inReplyTo":"1219920145.7107.273.camel@pmac.infradead.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T19:56:29Z","receivedAt":"2008-08-28T19:56:29Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 28, 2008, at 3:42 AM, David Woodhouse wrote:\n\n> On Thu, 2008-08-28 at 03:33 -0700, Perry Wagle wrote:\n>> Are you suggesting that I break into machines that I don't have \n>> access\n>> to add a export PATH= line to copies of scripts that were written 6\n>> months ago, and worked just fine until someone decided that \"upward\n>> compatibility\" wasn't an important concept?\n>\n> Not at all. But as long as you also refrain from breaking into those\n> same machines and upgrading them to git 1.6.0, you should be fine.\n\nI was being over-dramatic in an attempt to get people to at least try \nto think it out. You did, thanks!\n\nBut the actual problem is that I provide a central repository with \n\"the current version of git\" for us. I'm not sure who all pulls from \nthat repository, but a number of them have finally learned git well \nenough to clamor for 1.6.0.\n\nSo it's them upgrading from my repository, not me upgrading for them.\n\n> Or if you _do_ upgrade them to git 1.6.0, you should make sure you \n> build\n> with gitexecdir=/usr/bin to prevent the breakage.\n\nThat's a hack, which will burn me in less than a year.\n\n> What distribution are you running on those machines? If they upgrade\n> their version of git from an earlier version to 1.6.0 in a stable\n> release without setting gitexecdir=/usr/bin to preserve compatibility,\n> then the packager needs to be taken out back and shot.\n\nI'm the packager. I didn't upgrade our customized version of git \nbecause I'm still trying to think it out.\n\nI don't get to break things. If I break them, I gotta fix them. I \nhaven't been paid to do git stuff for months, and I have a deadline \ntomorrow. But I gotta act now if I want a chance to live a life \nwithout the git community breaking upward compatibility on minor \nversion releases for completely frivolous reasons. It wasn't broke, \nbut you \"fixed\" it anyway. What's next?\n\nI'm more worried about what's next and what's already slipped through \nthan this one particular thing.\n\n-- Perry\n"},{"id":"88961","messageId":"7v63pkew9l.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080828191956.GA7906@flint.arm.linux.org.uk","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-28T20:10:14Z","receivedAt":"2008-08-28T20:10:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Russell King writes:\n\n> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:\n>> Russell King wrote:\n>> >And no warnings before hand that the commands you were using were\n>> >deprecated.\n>> \n>> (a) They weren't deprecated, they were moved into a different directory.\n>\n> I think Junio will tell you differently on the \"deprecation\" bit.\n\nThe short answer is \"no, not anymore\".\n\nI might have ;-), if you asked me a few days ago, and the topic of this\nthread was exactly to decide the answer to that question, which was\nconcluded with $gmane/93793.\n\n>> (b) There have been several announcements of the 1.6.0 prereleases and \n>> the 1.6.0 release crossposted. Of course somebody forgot to tell you \n>> what you will learn from these release notes. Unfair.\n>\n> Cross posting to high traffic mailing lists doesn't guarantee that\n> it'll be read. It's the wrong place to do it.\n>\n> Arguably, though, the lack of information to users on the system affected\n> is not git maintainers fault. It's the fault of the admins on that system\n> not having read the release notes themselves, and warning their users (for\n> whom git is a *critical* bit of software) that an upgrade is going to take\n> place, and they should read such-and-such.\n>\n> Like a note in the system MOTD.\n\nI've heard enough of \"the changes in 1.6.0 was underadvertised and caused\nusers pain\". I am now aware that git has more mature and its userbase has\nbroadened beyond populations that read release notes (I rarely read\nrelease notes to updates to vim or coreutils either, and that is showing\nthe maturity of the packages -- nothing to complain about and I am not\ncomplaining).\n\nBut so far nobody gave \"here is how I would have advertised it\", until\nyou wrote above. Thanks.\n\nBut that is not something _I_ could have done (and no, \"I wouldn't have\naccepted the change\" is not an option at this point). Are there things\nthat the maintainer could have done better?\n\nI think it is fair to say that I have vetoed and am still vetoing many \"UI\nclean-ups\" that propose to change things in a way that \"should have been\nthis way for consistency's sake from day one, if there were no existing\nuser base\". During discussions to shoot down such proposals, I take\nopinions from early adopters (that's you, kernel, wine and x.org people)\nvery seriously, perhaps to the point that outsiders would feel I am giving\nthem disproportionately large vetoing power. Sadly, those \"opinions from\neraly adopters\" are less and less \"real\" but more \"I'd imagine the early\nadopters would say...\" these days. The process would work better if early\nadopters do their part to help me by speaking up when it matters from time\nto time.\n"},{"id":"88964","messageId":"4B9831F7-3CB8-49CB-A1DB-111481A271FE@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828195211.GA3545@mithlond.arda.local","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T20:23:50Z","receivedAt":"2008-08-28T20:23:50Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote:\n\n> Perry Wagle wrote (2008-08-28 12:24 -0700):\n>\n>> Is is really only that I\n>>\n>> sed s/git-/git/g\n>>\n>> on the scripts? I'm doubting it, given the quality of reasoning and\n>> lack of respect for upward compatibility on this thread.\n>\n> I have come to understand that \"git \" has quite long time been more\n> robust and portable way of writing scripts. They work in both\n> configurations so I'd definitely suggest doing \"s/git-/git /g\" for \n> every\n> script. Of course in an interactive shell everyone can use whatever \n> they\n> prefer and works at the moment.\n\nSure. Its an extra fork in git command intensive scripts (and git is \nracey still maybe), but *shrug*.\n\nWhen I started with git in Fall 2007, the sample scripts and gitweb \nboth used git and git willy-nilly. I liked git \nbetter since it was what I used at the command line for the \ncompletion for the commands and for the man pages, and I like being \nmeticulously consistent so I can greatly reduce mistakes.\n\nEven as of March 2008 (our last sync with git before the git scripting \nwas completed and we got on to other things), the sample scripts and \ngitweb still used the git form. If this has been brewing for \ntwo years, there shouldn't have been a git form in the scripts \nin the standard source *anywhere* for those two years.\n\nThere was. Therefore, you don't get to claim that this was decided \ntwo years ago, finally done now, and what's Perry's problem anyway?\n\nBut, my problem is not git vs git, but the slap-dash way \nupward compatibility was broken and the \"water over the dam\" slippery \nslope rationalizations that refuse to consider reverting. \"You\" will \ndo it again in the future since you are declaring success here. And \n\"you\" have likely done it in the past 6 months.\n\n-- Perry\n"},{"id":"88966","messageId":"20080828203040.GQ18340@parisc-linux.org","threadId":"15184","inReplyTo":"7v63pkew9l.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthew Wilcox","fromEmail":"matthew@wil.cx","sentAt":"2008-08-28T20:30:41Z","receivedAt":"2008-08-28T20:30:41Z","isPatch":false,"sender":{"key":"matthew@wil.cx","avatar":null},"body":"On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote:\n> I think it is fair to say that I have vetoed and am still vetoing many \"UI\n> clean-ups\" that propose to change things in a way that \"should have been\n> this way for consistency's sake from day one, if there were no existing\n> user base\". During discussions to shoot down such proposals, I take\n> opinions from early adopters (that's you, kernel, wine and x.org people)\n> very seriously, perhaps to the point that outsiders would feel I am giving\n> them disproportionately large vetoing power. Sadly, those \"opinions from\n> eraly adopters\" are less and less \"real\" but more \"I'd imagine the early\n> adopters would say...\" these days. The process would work better if early\n> adopters do their part to help me by speaking up when it matters from time\n> to time.\n\nI think it's fairly clear by now that we aren't shy about sharing our\nopinions ... if we're asked for them. So do we need a git-oldtimers\nmailing list where you can post proposals so we can NACK them?\n\n-- \nMatthew Wilcox\t\t\t\tIntel Open Source Technology Centre\n\"Bill, look, we understand that you're interested in selling us this\noperating system, but compare it to ours. We can't possibly take such\na retrograde step.\"\n"},{"id":"88967","messageId":"20080828203631.GX10360@machine.or.cz","threadId":"15184","inReplyTo":"7v63pkew9l.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-28T20:36:31Z","receivedAt":"2008-08-28T20:36:31Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 28, 2008 at 01:10:14PM -0700, Junio C Hamano wrote:\n> I think it is fair to say that I have vetoed and am still vetoing many \"UI\n> clean-ups\" that propose to change things in a way that \"should have been\n> this way for consistency's sake from day one, if there were no existing\n> user base\". During discussions to shoot down such proposals, I take\n> opinions from early adopters (that's you, kernel, wine and x.org people)\n> very seriously, perhaps to the point that outsiders would feel I am giving\n> them disproportionately large vetoing power. Sadly, those \"opinions from\n> eraly adopters\" are less and less \"real\" but more \"I'd imagine the early\n> adopters would say...\" these days. The process would work better if early\n> adopters do their part to help me by speaking up when it matters from time\n> to time.\n\nI think just freezing the UI is not a good answer. Git's UI evolved too\nwildly and uncontrollably in the early days and I think in the long run,\ntweaking out at least some of the inconsistencies is good idea, IMHO.\nNot that I would think there should be any more *major* changes\nupcoming, I mean mostly small stuff (all that I hate the\ngit-checkout/git-reset dichotomy or git-add/git-rm asymetry, touching\nthis would be just too radical change by now, IMHO).\n\nThe only problem I can see with the transition were the deprecation\nmessages, as was mentioned much earlier in the thread. If it's going\naway in few years, Git should start to nag about it now. Then, all whom\nit concerns _will_ realize this and slowly transition at their own pace.\nAlso, maybe we should require all internal references and documentation\nupdated when *declaring the feature deprecated* (not when removing it),\neven if it means delaying the phase-out; that was the other major\ncomplaint in this thread that is worth remembering, I believe.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"88970","messageId":"B0BAA28F-C029-411B-BE86-3A63951CE213@cs.indiana.edu","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808280936300.3300@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T20:42:22Z","receivedAt":"2008-08-28T20:42:22Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote:\n\n> On Thu, 28 Aug 2008, Felipe Contreras wrote:\n>>\n>> If the git-foo was supposed to be deprecated in 1.6.0\n>\n> Itw as deprecated over a _year_ ago.\n\nNo, it wasn't. As of March 2008, git was still in the sample \nhooks and in git-web. That was the last time I did anything with git \nscripting. It was something between then and now that the 's \nwere finally removed.\n\nOh wait:\n\n dhcp-2:git wagle$ grep -r --color git- . | wc -l\n 6580\n dhcp-2:git wagle$\n\nNo, I'm not going to figure out which are okay, and which aren't. \nI'll just assume that they are all okay, but leave you to wonder.\n\n-- Perry\n\nPS. Okay, fine! Here's as far as I got before getting bored:\n\n grep -r git- . | cat -v | sed \"s/^.*\\(git-[^ :\\\")\\[($\\']*\\).*$/ \n\\1/\" | sort | uniq\n"},{"id":"88969","messageId":"20080828204418.GY10360@machine.or.cz","threadId":"15184","inReplyTo":"4B9831F7-3CB8-49CB-A1DB-111481A271FE@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-28T20:44:18Z","receivedAt":"2008-08-28T20:44:18Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:\n>\n> On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote:\n>\n>> I have come to understand that \"git \" has quite long time been more\n>> robust and portable way of writing scripts. They work in both\n>> configurations so I'd definitely suggest doing \"s/git-/git /g\" for every\n>> script. Of course in an interactive shell everyone can use whatever they\n>> prefer and works at the moment.\n>\n> Sure. Its an extra fork in git command intensive scripts (and git is racey \n> still maybe), but *shrug*.\n\nDo you have any details on the races in Git you know about?\n\nThis does not mean an extra fork, only extra exec. In case of builtin\ncommands (which is actually a large majority by now), not even that.\n\n> Even as of March 2008 (our last sync with git before the git scripting was \n> completed and we got on to other things), the sample scripts and gitweb \n> still used the git form. If this has been brewing for two years, \n> there shouldn't have been a git form in the scripts in the standard \n> source *anywhere* for those two years.\n\nI agree that this is a problem. Even now, the documentation is using\ngit- at plenty of places. Patches are welcome, I'm sure.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"88978","messageId":"48B71128.8040400@s5r6.in-berlin.de","threadId":"15184","inReplyTo":"20080828191956.GA7906@flint.arm.linux.org.uk","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Stefan Richter","fromEmail":"stefanr@s5r6.in-berlin.de","sentAt":"2008-08-28T20:57:12Z","receivedAt":"2008-08-28T20:57:12Z","isPatch":false,"sender":{"key":"stefanr@s5r6.in-berlin.de","avatar":null},"body":"Russell King wrote:\n> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:\n>> \"-\" -> \" \"? Molehill.\n> \n> \"ls\" -> \"listfiles\" - how would you feel about that change happening\n> behind your back?\n\nI would feel betrayed, then add another alias to .bashrc, then feel \ndeeply satisfied by my cunning betrayal of the betrayers, knowing that \nonly a true genius hacker could come up with a countermeasure like that.\n-- \nStefan Richter\n-=====-==--- =--- ===--\nhttp://arcgraph.de/sr/\n"},{"id":"88980","messageId":"59946C4A-CFA4-430E-BF90-A90A445EAB9E@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828204418.GY10360@machine.or.cz","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T20:57:59Z","receivedAt":"2008-08-28T20:57:59Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 28, 2008, at 1:44 PM, Petr Baudis wrote:\n\n> On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:\n>>\n>> On Aug 28, 2008, at 12:52 PM, Teemu Likonen wrote:\n>>\n>>> I have come to understand that \"git \" has quite long time been more\n>>> robust and portable way of writing scripts. They work in both\n>>> configurations so I'd definitely suggest doing \"s/git-/git /g\" for \n>>> every\n>>> script. Of course in an interactive shell everyone can use \n>>> whatever they\n>>> prefer and works at the moment.\n>>\n>> Sure. Its an extra fork in git command intensive scripts (and git \n>> is racey\n>> still maybe), but *shrug*.\n>\n> Do you have any details on the races in Git you know about?\n\nSorry, I should have just left that line out. But I didn't, so:\n\nFall of 2007, I'd get spurious reports that the working dir was \ninconsistent when iterating through 612 commits in a script (I was \nconverting from quilt/cvs to git) when it wasn't. I got around most \nof this by sprinkling the script with git-status and git update-index \n--refresh. My understanding was that it really was the one-second \ngranularity of the timestamps on my file system doing it, so nothing \nfor me to do at the time.\n\nHowever, it was really bugging people, so I figured by this time \nsomeone had found a clever way to fix it, hence the \"maybe\".\n\nI haven't tried it for a while.\n\n> This does not mean an extra fork, only extra exec. In case of builtin\n> commands (which is actually a large majority by now), not even that.\n\nYeah, I should have deleted that line. 8)\n\n\n>> Even as of March 2008 (our last sync with git before the git \n>> scripting was\n>> completed and we got on to other things), the sample scripts and \n>> gitweb\n>> still used the git form. If this has been brewing for two \n>> years,\n>> there shouldn't have been a git form in the scripts in the \n>> standard\n>> source *anywhere* for those two years.\n>\n> I agree that this is a problem. Even now, the documentation is using\n> git- at plenty of places. Patches are welcome, I'm sure.\n\nHeh.\n\n-- Perry\n"},{"id":"88988","messageId":"58E42279-D489-4356-9B4C-148A95F402E5@cs.indiana.edu","threadId":"15184","inReplyTo":"48B71128.8040400@s5r6.in-berlin.de","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T21:05:42Z","receivedAt":"2008-08-28T21:05:42Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 28, 2008, at 1:57 PM, Stefan Richter wrote:\n\n> Russell King wrote:\n>> On Thu, Aug 28, 2008 at 01:53:50AM +0200, Stefan Richter wrote:\n>>> \"-\" -> \" \"? Molehill.\n>> \"ls\" -> \"listfiles\" - how would you feel about that change happening\n>> behind your back?\n>\n> I would feel betrayed, then add another alias to .bashrc, then feel \n> deeply satisfied by my cunning betrayal of the betrayers, knowing \n> that only a true genius hacker could come up with a countermeasure \n> like that.\n\nWhen I started with VMS (ahem) years ago, my buddies handed me eunice \n(a unix like environment) and a big bag of aliases to make my \nenvironment look like unix. I did this for years and was happy.\n\nBut one day I lost my command shell init scripts, and was left to fend \nfor myself with pure VMS commands. I was completely helpless. Moral: \nnever again will I customize my programming environment to that extent.\n\nYour solution is that sort of over-customization. Sticking git's \nlibexec in your path is too. I'm still allergic.\n\n-- Perry\n\nPS. \n"},{"id":"89010","messageId":"20080828212346.GA27867@coredump.intra.peff.net","threadId":"15184","inReplyTo":"4B9831F7-3CB8-49CB-A1DB-111481A271FE@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T21:23:47Z","receivedAt":"2008-08-28T21:23:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:\n\n> But, my problem is not git vs git, but the slap-dash way \n> upward compatibility was broken and the \"water over the dam\" slippery \n> slope rationalizations that refuse to consider reverting. \"You\" will do \n> it again in the future since you are declaring success here. And \"you\" \n> have likely done it in the past 6 months.\n\nI don't think Junio is declaring success. In fact, I think he has sent\nseveral messages saying (paraphrasing of course):\n\n - this was obviously not done in the best manner possible, because of\n the number of people complaining\n\n - we will try to do better about notification next time such a change\n is made. Please make suggestions about how to do so.\n\n - since we have already released and already broken everybody, and\n these people are now complaining on the list, there is not much\n point in trying to notify people of _this_ change now\n\nJunio (and others) have tried to be very careful about breaking\nbackwards compatibility, especially for scripting interfaces. We thought\nsufficient steps were taken this time, but clearly some disagree.\n\nSo please stop making specious claims that there are crazy\nbackwards-incompatibility bugs lurking throughout new versions of git.\nIf there are, then please find and name them. If not, then I think the\ngit community would welcome suggestions about how better to notify users\nabout the rare changes like this one.\n\n-Peff\n"},{"id":"89016","messageId":"1C144B19-DA21-4CB4-B872-C1F154B031CF@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828212346.GA27867@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T21:41:52Z","receivedAt":"2008-08-28T21:41:52Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 28, 2008, at 2:23 PM, Jeff King wrote:\n\n> On Thu, Aug 28, 2008 at 01:23:50PM -0700, Perry Wagle wrote:\n>\n>> But, my problem is not git vs git, but the slap-dash way\n>> upward compatibility was broken and the \"water over the dam\" slippery\n>> slope rationalizations that refuse to consider reverting. \"You\" \n>> will do\n>> it again in the future since you are declaring success here. And \n>> \"you\"\n>> have likely done it in the past 6 months.\n>\n> I don't think Junio is declaring success. In fact, I think he has sent\n> several messages saying (paraphrasing of course):\n\nI did not name anyone, and put \"you\" in quotes to try to not even \nimply I was pointing at one person. Several people have declared \nsuccess, but Junio wasn't one of them. I think (?) that he was just \nthe unwilling gunman. 8)\n\n> So please stop making specious claims that there are crazy\n> backwards-incompatibility bugs lurking throughout new versions of git.\n> If there are, then please find and name them. If not, then I think the\n> git community would welcome suggestions about how better to notify \n> users\n> about the rare changes like this one.\n\nI now have to TEST to find those crazy backwards-incompatibility bugs \nbefore I can upgrade us to 1.6.0. To test, I have to try to imagine \nwhat I and others were assuming about git. And this episode means \nthat I can't make any assumptions about the sanity of any changes \nsince March, which is the version I'm thinking of upgrading.\n\nBut note that THIS upward compatibility bug has been declared to not \nbe a bug. Will any others receive the same stamp?\n\nSo please put on your engineer hat, and stop talking about \"specious \nclaims\" and hurting feelings. Heck, I even got Linus himself to ask \nif us people were on drugs, and I didn't take it personally. At least \nI'm saying something that can be disputed, and not ad hominem like \nLinus. 8)\n\nHow to better notify them is to do it on a major release, like Git \n2.0. THEN, they expect upward compatibility to break.\n\n-- Perry\n"},{"id":"89019","messageId":"20080828215335.GA10360@machine.or.cz","threadId":"15184","inReplyTo":"1C144B19-DA21-4CB4-B872-C1F154B031CF@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-28T21:53:35Z","receivedAt":"2008-08-28T21:53:35Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"It's getting repetitive. :-(\n\nOn Thu, Aug 28, 2008 at 02:41:52PM -0700, Perry Wagle wrote:\n> I now have to TEST to find those crazy backwards-incompatibility bugs \n> before I can upgrade us to 1.6.0. To test, I have to try to imagine what I \n> and others were assuming about git. And this episode means that I can't \n> make any assumptions about the sanity of any changes since March, which is \n> the version I'm thinking of upgrading.\n\nAll changes of this kind, including this one, should be carefully\ndescribed in the release notes. Since you say you are effectively a Git\npackager, you really should be one of the persons who do actually read\nthem. :-)\n\nYou can't ask us to stop making any incompatible changes - Git is still\ntoo young for that and it's UI got evolved, not designed. But we do\ndocument the changes we do, even though we might do a better job\n*spreading* the word.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"89021","messageId":"20080828215907.GE27867@coredump.intra.peff.net","threadId":"15184","inReplyTo":"1C144B19-DA21-4CB4-B872-C1F154B031CF@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T21:59:08Z","receivedAt":"2008-08-28T21:59:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 02:41:52PM -0700, Perry Wagle wrote:\n\n>>> But, my problem is not git vs git, but the slap-dash way\n>>> upward compatibility was broken and the \"water over the dam\" slippery\n>>> slope rationalizations that refuse to consider reverting. \"You\" will \n>>> do\n>>> it again in the future since you are declaring success here. And \n>>> \"you\"\n>>> have likely done it in the past 6 months.\n>>\n>> I don't think Junio is declaring success. In fact, I think he has sent\n>> several messages saying (paraphrasing of course):\n>\n> I did not name anyone, and put \"you\" in quotes to try to not even imply I \n> was pointing at one person. Several people have declared success, but \n> Junio wasn't one of them. I think (?) that he was just the unwilling \n> gunman. 8)\n\nSorry, I thought you meant \"the git community has put these bugs into\ngit\" in the past 6 months. And I don't think that is true.\n\n> I now have to TEST to find those crazy backwards-incompatibility bugs \n> before I can upgrade us to 1.6.0. To test, I have to try to imagine what \n> I and others were assuming about git. And this episode means that I can't \n> make any assumptions about the sanity of any changes since March, which is \n> the version I'm thinking of upgrading.\n>\n> But note that THIS upward compatibility bug has been declared to not be a \n> bug. Will any others receive the same stamp?\n>\n> So please put on your engineer hat, and stop talking about \"specious \n> claims\" and hurting feelings.\n\nMy engineer hat _is_ on. Here is the logic that led to my use of the\nphrase \"specious claims\":\n\n - you are claiming that there are backwards incompatibility changes\n lurking in git (or at least that is what I believe you to mean)\n\n - there has been _one_ such problem, and the person responsible for\n vetting such changes has solicited suggestions for doing better in\n the future. I don't think that is indicative of a pattern of such\n changes.\n\n - But let's say you have lost some faith in the git development\n process due to _this_ bug. But let's look at the history of this\n bug. It has been discussed several times for the past 2 years, along\n with a mention in the release notes several versions ago. It was not\n a surprise to anybody who has been developing git.\n\n So yes, maybe there _are_ other bugs just like it lurking. But\n wouldn't it stand to reason that those bugs have _also_ been\n discussed and mentioned in the release notes, or that the developers\n would know about them?\n\n In other words, I can see you losing enough faith to say \"wow, the\n git developers don't communicate very well and I need to vet their\n changes and notes more carefully\". I don't think it is reasonable to\n say that there are likely to be other, totally unknown backwards\n incompatible changes.\n\nSo\n\n 1. I find your claim that such bugs exist to have little evidence to\n back it up.\n\n 2. As an engineer, I have seen evidence of one problem (insufficient\n communication) but not of another (introduction of\n incompatibilities without on-list discussion). So I would choose to\n focus my resources on fixing the problem I have seen.\n\n> Heck, I even got Linus himself to ask if us people were on drugs, and\n> I didn't take it personally. At least I'm saying something that can\n> be disputed, and not ad hominem like Linus. 8)\n\nSorry, but I'm not impressed by your getting Linus to yell at you. It's\nlike shooting fish in a barrel. :)\n\n> How to better notify them is to do it on a major release, like Git 2.0. \n> THEN, they expect upward compatibility to break.\n\nNow that _is_ a reasonable suggestion. This change _did_ wait until the\njump to 1.6.0, which we thought of as a major version jump (just as 1.4\nto 1.5 introduced a few minor but documented changes). I don't think\nthere is a plan for \"git 2.0\" short of serious incompatibilities in the\nrepo format (i.e., you can't use 2.x tools on 1.x repos and vice versa).\nSo perhaps our numbering should be more emphatic.\n\n-Peff\n"},{"id":"89026","messageId":"3DE083DB-ADFF-45E7-B3EB-A76985941271@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828215907.GE27867@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T22:33:26Z","receivedAt":"2008-08-28T22:33:26Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"\nOn Aug 28, 2008, at 2:59 PM, Jeff King wrote:\n\n>> I now have to TEST to find those crazy backwards-incompatibility bugs\n>> before I can upgrade us to 1.6.0. To test, I have to try to \n>> imagine what\n>> I and others were assuming about git. And this episode means that \n>> I can't\n>> make any assumptions about the sanity of any changes since March, \n>> which is\n>> the version I'm thinking of upgrading.\n>>\n>> But note that THIS upward compatibility bug has been declared to \n>> not be a\n>> bug. Will any others receive the same stamp?\n>>\n>> So please put on your engineer hat, and stop talking about \"specious\n>> claims\" and hurting feelings.\n>\n> My engineer hat _is_ on. Here is the logic that led to my use of the\n> phrase \"specious claims\":\n\nCool. Thanks! (seriously)\n\n> - you are claiming that there are backwards incompatibility changes\n> lurking in git (or at least that is what I believe you to mean)\n\nI'm saying that I don't know and will have to do complete exhaustive \ntesting to be sure (my faith in git has been severely shaken). I \nalready tested every step for months, and to do it \"right\", I have to \ndo that all over again. I don't have the time, so I have to do severe \napproximations. One of the fixes is to see if I can get people to \nstop making frivolous changes: \"ooo! we have to rename everything in \nthe API because lists, I mean hashtables, with 143 entries in them are \noffensive!\". If there was more reasoning than that, it was not \ndisplayed in this thread.\n\n\n> - there has been _one_ such problem, and the person responsible for\n> vetting such changes has solicited suggestions for doing better in\n> the future. I don't think that is indicative of a pattern of such\n> changes.\n\nOk. My suggestion is that it shouldn't have been done in the first \nplace, and we should now revert. But others are saying over and over \n\"its done! live with it!\". I came in late. What did I miss in the \nlast 6 months. Sounds like people have lots of practice with these \nwater-over-the-dam's, surely this isn't the first time?\n\n> - But let's say you have lost some faith in the git development\n> process due to _this_ bug. But let's look at the history of this\n> bug. It has been discussed several times for the past 2 years, \n> along\n> with a mention in the release notes several versions ago. It was \n> not\n> a surprise to anybody who has been developing git.\n\nIn March 2008, the sample git-hooks and git-web used git \ncommands. That was the last I looked at git until Tuesday of this week.\n\n> So yes, maybe there _are_ other bugs just like it lurking. But\n> wouldn't it stand to reason that those bugs have _also_ been\n> discussed and mentioned in the release notes, or that the \n> developers\n> would know about them?\n\nThis is declared to not be a bug, even though it breaks existing \nscripts, even those published in the main branch of git itself.\n\n> In other words, I can see you losing enough faith to say \"wow, the\n> git developers don't communicate very well and I need to vet their\n> changes and notes more carefully\". I don't think it is reasonable \n> to\n> say that there are likely to be other, totally unknown backwards\n> incompatible changes.\n\nI'm going by the reasoning shown in this thread. Why not? I'm \nlooking for a way not to have to do exhaustive testing on those \nscripts, so would love to hear it.\n\n> So\n>\n> 1. I find your claim that such bugs exist to have little evidence to\n> back it up.\n\nInduction. If it happened once, it probably happened more than once. \nThis wasn't a show stopper problem. It wasn't broke, but it was \n\"fixed\" anyway.\n\n> 2. As an engineer, I have seen evidence of one problem (insufficient\n> communication) but not of another (introduction of\n> incompatibilities without on-list discussion). So I would choose \n> to\n> focus my resources on fixing the problem I have seen.\n\nI don't know what I missed, and am not sure how to search for in in \nten thousand messages or so since March. My style is to anticipate \nproblems.\n\nBut I'll figure it out. Part of that figure out process is posting to \nthis thread.\n\n>> Heck, I even got Linus himself to ask if us people were on drugs, and\n>> I didn't take it personally. At least I'm saying something that can\n>> be disputed, and not ad hominem like Linus. 8)\n>\n> Sorry, but I'm not impressed by your getting Linus to yell at you. \n> It's\n> like shooting fish in a barrel. :)\n\nYeah, well, that was supposed to be both a joke and to indicate that \nI'm not sitting here with steam coming out my ears.\n\nLinus has his solution, that doesn't work for me. He hasn't listened \nto my several attempts to say why, and he's mad because he thinks I'm \nnot listening. But I expect he's a busy guy with 10,000 emails a day \nto respond to, so them's the breaks.\n\n>> How to better notify them is to do it on a major release, like Git \n>> 2.0.\n>> THEN, they expect upward compatibility to break.\n>\n> Now that _is_ a reasonable suggestion. This change _did_ wait until \n> the\n> jump to 1.6.0, which we thought of as a major version jump (just as \n> 1.4\n> to 1.5 introduced a few minor but documented changes). I don't think\n> there is a plan for \"git 2.0\" short of serious incompatibilities in \n> the\n> repo format (i.e., you can't use 2.x tools on 1.x repos and vice \n> versa).\n> So perhaps our numbering should be more emphatic.\n\nI think I hear you. Since git is young, I should expect \nincompatibilities with minor version changes, and not demand that they \nbe held off for major version changes. That seems very plausible.\n\nBut I think I'll still remain wary because 1.6 introduced a nearly \ncomplete renaming of the API for what, in this thread anyway, \ncompletely silly reasons. If there are good reasons, I haven't seen \nthem.\n\n-- Perry\n"},{"id":"89030","messageId":"m3prnsrbdp.fsf@localhost.localdomain","threadId":"15184","inReplyTo":"B0BAA28F-C029-411B-BE86-3A63951CE213@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-28T23:03:08Z","receivedAt":"2008-08-28T23:03:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Perry Wagle writes:\n\n> On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote: \n>> On Thu, 28 Aug 2008, Felipe Contreras wrote:\n>>>\n>>> If the git-foo was supposed to be deprecated in 1.6.0\n>>\n>> Itw as deprecated over a _year_ ago.\n> \n> No, it wasn't. As of March 2008, git was still in the sample\n> hooks and in git-web. [...]\n\nIf by \"git-web\" you mean \"gitweb\", the git web interface in Perl, this\nis simply not true. From the commit 25691fb (gitweb: Use --git-dir\nparameter instead of setting $ENV{'GIT_DIR'}) _at least_ gitweb uses\n\"git \" and not \"git-cmd\" form. And this commit was on 28 August\n2006, so in March 2008 gitweb didn't use git form...\n\nCheck your facts, please...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"89031","messageId":"20080828230401.GC29609@coredump.intra.peff.net","threadId":"15184","inReplyTo":"3DE083DB-ADFF-45E7-B3EB-A76985941271@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T23:04:01Z","receivedAt":"2008-08-28T23:04:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:\n\n> Ok. My suggestion is that it shouldn't have been done in the first \n> place, and we should now revert. But others are saying over and over \n> \"its done! live with it!\". I came in late. What did I miss in the last \n> 6 months. Sounds like people have lots of practice with these \n> water-over-the-dam's, surely this isn't the first time?\n\nNo, it really is the first time.\n\n> In March 2008, the sample git-hooks and git-web used git commands. \n> That was the last I looked at git until Tuesday of this week.\n\nYes, and some of the test scripts still have git-* in them. I think in\nthat respect, the git community has been very bad about eating our own\ndog food.\n\n>> So yes, maybe there _are_ other bugs just like it lurking. But\n>> wouldn't it stand to reason that those bugs have _also_ been\n>> discussed and mentioned in the release notes, or that the developers\n>> would know about them?\n>\n> This is declared to not be a bug, even though it breaks existing scripts, \n> even those published in the main branch of git itself.\n\nI think the bug is not in the change, but in the deprecation process and\ncommunication. But I think the definition of \"bug\" is vague enough to\nsimply be in the eye of the beholder.\n\n> I'm going by the reasoning shown in this thread. Why not? I'm looking \n> for a way not to have to do exhaustive testing on those scripts, so would \n> love to hear it.\n\nUltimately you must be the judge of what and how much to test on your\nsystems. But if you are asking if there are other similar compatibility\nbugs in 1.6.0, then my opinion, as somebody who follows the git list\nquite closely and contributes some code, is that no, there are not.\n\n>> 1. I find your claim that such bugs exist to have little evidence to\n>> back it up.\n>\n> Induction. If it happened once, it probably happened more than once. \n> This wasn't a show stopper problem. It wasn't broke, but it was \"fixed\" \n> anyway.\n\nInduction in this manner is not a very rigorous argument (we're being\nengineers, right?). I gave several reasons already why the probability\nis low that another such bug exists, mostly related to the lack of\nindicators.\n\n> I don't know what I missed, and am not sure how to search for in in ten \n> thousand messages or so since March. My style is to anticipate problems.\n\nSure, I wouldn't want to go back and read all of the messages either.\nBut this was mentioned in the release notes, too. Why don't you start\nwith them?\n\n> I think I hear you. Since git is young, I should expect \n> incompatibilities with minor version changes, and not demand that they be \n> held off for major version changes. That seems very plausible.\n\nThat isn't quite what I meant. What I meant was that our idea of a major\nversion number is the middle number. That is, the time to introduce a\nfew minor incompatibilities is when that number jumps (but they should\nbe documented for a significant time period ahead of time, which this\nwas). I don't expect to jump to \"git 2.0\" basically ever. Just as I\ndon't really expect Linux 3.0 anytime soon. But I, of course, am not in\ncharge of such things, so you may take that with a grain of salt.\n\n> But I think I'll still remain wary because 1.6 introduced a nearly \n> complete renaming of the API for what, in this thread anyway, completely \n> silly reasons. If there are good reasons, I haven't seen them.\n\nI think the reasons have been mentioned a few times. Maybe you just\ndidn't think they were good.\n\n-Peff\n"},{"id":"89034","messageId":"881C17DA-2FE2-49A7-A4A9-FACA7720599C@cs.indiana.edu","threadId":"15184","inReplyTo":"3DE083DB-ADFF-45E7-B3EB-A76985941271@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T23:12:18Z","receivedAt":"2008-08-28T23:12:18Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"Jeff King has convinced me that it's perfectly legitimate to introduce \nnon-upward compatibilities in minor version releases of \"young\" \nsoftware.\n\nMy introduction to the problem was Tuesday of this week and this \nthread. The reasoning that I generally saw in this thread was insane, \nand it scared me. With some of the feedback I received, I now see a \nbigger picture where these decisions aren't so willy-nilly.\n\nI think the lesson here, however, it that the correct way to have done \nthis is to first remove all the git's from the source, demos, \nsample, documentation, etc. Second, BIG PAUSE (full minor version \nrelease cycle?) Then, third, get rid of git in /bin.\n\nThe doctor expects my full recovery tomorrow. 8)\n\nThanks!\n\n-- Perry\n"},{"id":"89035","messageId":"CD2FC91F-D5BB-486D-B138-F521A493FE73@cs.indiana.edu","threadId":"15184","inReplyTo":"m3prnsrbdp.fsf@localhost.localdomain","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T23:14:14Z","receivedAt":"2008-08-28T23:14:14Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"I did:\n\npwagle@starscream:/usr/lib/cgi-bin$ ls -l\ntotal 352\n-rw-r--r-- 1 root root 164 2008-03-07 12:03 git-favicon.png\n-rw-r--r-- 1 root root 208 2008-03-07 12:03 git-logo.png\n-rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi\n-rw-r--r-- 1 root root 7112 2008-03-07 12:03 gitweb.css\n-rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl\npwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l\n68\npwagle@starscream:/usr/lib/cgi-bin$\n\nOn Aug 28, 2008, at 4:03 PM, Jakub Narebski wrote:\n\n> Perry Wagle writes:\n>\n>> On Aug 28, 2008, at 9:37 AM, Linus Torvalds wrote:\n>>> On Thu, 28 Aug 2008, Felipe Contreras wrote:\n>>>>\n>>>> If the git-foo was supposed to be deprecated in 1.6.0\n>>>\n>>> Itw as deprecated over a _year_ ago.\n>>\n>> No, it wasn't. As of March 2008, git was still in the sample\n>> hooks and in git-web. [...]\n>\n> If by \"git-web\" you mean \"gitweb\", the git web interface in Perl, this\n> is simply not true. From the commit 25691fb (gitweb: Use --git-dir\n> parameter instead of setting $ENV{'GIT_DIR'}) _at least_ gitweb uses\n> \"git \" and not \"git-cmd\" form. And this commit was on 28 August\n> 2006, so in March 2008 gitweb didn't use git form...\n>\n> Check your facts, please...\n>\n> -- \n> Jakub Narebski\n> Poland\n> ShadeHawk on #git\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"89038","messageId":"4018E8E1-9C23-4AED-BA78-6E889A32E691@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828230401.GC29609@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T23:22:12Z","receivedAt":"2008-08-28T23:22:12Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"On Aug 28, 2008, at 4:04 PM, Jeff King wrote:\n\n> On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:\n>\n>> But I think I'll still remain wary because 1.6 introduced a nearly\n>> complete renaming of the API for what, in this thread anyway, \n>> completely\n>> silly reasons. If there are good reasons, I haven't seen them.\n>\n> I think the reasons have been mentioned a few times. Maybe you just\n> didn't think they were good.\n\nWhat I saw was \"git produces a list of 143 commands. \nLong lists are inefficient. Get rid of it!\". Actually the list is a \nhash table in any reasonable shell. So its only aesthetics?\n\nBeing able to quickly see the list is very useful. That could be done \nwith git, except some people want that to be lobotomized \nto show only a fraction of the total. My mind boggles at that one.\n\nBut see my other post. I'm over it.\n\n-- Perry\n"},{"id":"89039","messageId":"7vmyiwd8ot.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080828230401.GC29609@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-28T23:24:50Z","receivedAt":"2008-08-28T23:24:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> In March 2008, the sample git-hooks and git-web used git commands. \n>> That was the last I looked at git until Tuesday of this week.\n>\n> Yes, and some of the test scripts still have git-* in them. I think in\n> that respect, the git community has been very bad about eating our own\n> dog food.\n\nNot at all.\n\nFor one thing, hooks do run under modified PATH, as already pointed out in\nthe earlier thread.\n\nTest scripts are executed in a special environment whose GIT_EXEC_PATH\npoints at the top of the build tree, where all git-foo lives.\n\nBefore anybody greps in Documentation/ to make pointless noises about some\ndashed-form git-foo in there when we do not talk about what the user types\nbut about a command as a concept in manual pages, they are left in dashed\nform deliberately, partly to help manpage browsers crosslink across pages.\n\nWe could have described typographic convention,\n\nCf.\n\n http://thread.gmane.org/gmane.comp.version-control.git/86940/focus=87008\n\nbut we ended up not doing so.\n"},{"id":"89041","messageId":"76E64CE4-758C-4215-BA46-A222A8D78C12@cs.indiana.edu","threadId":"15184","inReplyTo":"7vmyiwd8ot.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T23:28:34Z","receivedAt":"2008-08-28T23:28:34Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"My (ahem) implied point (sorry) also was that these \"hook\" scripts act \nas examples of how to write git scripts in general, and some of them \nare written to me run as regular scripts.\n\n-- Perry\n\nOn Aug 28, 2008, at 4:24 PM, Junio C Hamano wrote:\n\n> Jeff King writes:\n>\n>>> In March 2008, the sample git-hooks and git-web used git \n>>> commands.\n>>> That was the last I looked at git until Tuesday of this week.\n>>\n>> Yes, and some of the test scripts still have git-* in them. I think \n>> in\n>> that respect, the git community has been very bad about eating our \n>> own\n>> dog food.\n>\n> Not at all.\n>\n> For one thing, hooks do run under modified PATH, as already pointed \n> out in\n> the earlier thread.\n>\n> Test scripts are executed in a special environment whose GIT_EXEC_PATH\n> points at the top of the build tree, where all git-foo lives.\n>\n> Before anybody greps in Documentation/ to make pointless noises \n> about some\n> dashed-form git-foo in there when we do not talk about what the user \n> types\n> but about a command as a concept in manual pages, they are left in \n> dashed\n> form deliberately, partly to help manpage browsers crosslink across \n> pages.\n>\n> We could have described typographic convention,\n>\n> Cf.\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/86940/focus=87008\n>\n> but we ended up not doing so.\n"},{"id":"89040","messageId":"20080828233022.GB10360@machine.or.cz","threadId":"15184","inReplyTo":"7vmyiwd8ot.fsf@gitster.siamese.dyndns.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-08-28T23:30:22Z","receivedAt":"2008-08-28T23:30:22Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:\n> Before anybody greps in Documentation/ to make pointless noises about some\n> dashed-form git-foo in there when we do not talk about what the user types\n> but about a command as a concept in manual pages, they are left in dashed\n> form deliberately, partly to help manpage browsers crosslink across pages.\n\nWhat is the other part? And is it really worth the confusion? Are the\ngazillions cases of dashed-form git-foo in there where we DO talk about\nwhat the user types \"pointless noises\" too?\n\n(I have argued further in the other mail but somehow we seem to have\ngone off the list with that subthread, hmm.)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"89043","messageId":"m3ljygra2o.fsf@localhost.localdomain","threadId":"15184","inReplyTo":"3DE083DB-ADFF-45E7-B3EB-A76985941271@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-08-28T23:31:26Z","receivedAt":"2008-08-28T23:31:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Perry Wagle writes:\n\n> On Aug 28, 2008, at 2:59 PM, Jeff King wrote:\n> \n>>> I now have to TEST to find those crazy backwards-incompatibility\n>>> bugs before I can upgrade us to 1.6.0. To test, I have to try to\n>>> imagine what I and others were assuming about git. And this\n>>> episode means that I can't make any assumptions about the sanity\n>>> of any changes since March, which is the version I'm thinking of\n>>> upgrading.\n>>>\n>>> But note that THIS upward compatibility bug has been declared to\n>>> not be a bug. Will any others receive the same stamp?\n>>>\n>>> So please put on your engineer hat, and stop talking about \"specious\n>>> claims\" and hurting feelings.\n\n>> - there has been _one_ such problem, and the person responsible for\n>> vetting such changes has solicited suggestions for doing better in\n>> the future. I don't think that is indicative of a pattern of such\n>> changes.\n> \n> Ok. My suggestion is that it shouldn't have been done in the first\n> place, and we should now revert. But others are saying over and over\n> \"its done! live with it!\". I came in late. What did I miss in the\n> last 6 months. Sounds like people have lots of practice with these\n> water-over-the-dam's, surely this isn't the first time?\n\nErrr... what last 6 months? Using \"git \" over \"git-\"\n(also in scripts) was recommended for a long, long time' much more\nthan those 6 months.\n\nBesides, the question stated in this thread was not whether to move\n\"git-*\" commands outside $(bindir) (usually '/usr/bin'), but whether\nto not create or not links (or symlinks, or hardcopy) in gitexecdir.\n \n>> - But let's say you have lost some faith in the git development\n>> process due to _this_ bug. But let's look at the history of this\n>> bug. It has been discussed several times for the past 2 years, along\n>> with a mention in the release notes several versions ago. It was not\n>> a surprise to anybody who has been developing git.\n> \n> In March 2008, the sample git-hooks and git-web used git\n> commands. That was the last I looked at git until Tuesday of this\n> week.\n\nAs I said earlier in this thread, if by git-web you mean gitweb this\nis simply not true. _At least_ since commit 25691fb (gitweb: Use\n--git-dir parameter instead of setting $ENV{'GIT_DIR'}) gitweb used\ndashless form.\n\n> But I think I'll still remain wary because 1.6 introduced a nearly\n> complete renaming of the API for what, in this thread anyway,\n> completely silly reasons. If there are good reasons, I haven't seen\n> them.\n\nIIRC the reasons are git wrapper options linke --paginate or\n--git-dir, equal treatment of git aliases, and cluttering of bindir\n(which might be ~/bin).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"89044","messageId":"20080828233645.GF29609@coredump.intra.peff.net","threadId":"15184","inReplyTo":"4018E8E1-9C23-4AED-BA78-6E889A32E691@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T23:36:45Z","receivedAt":"2008-08-28T23:36:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"[dropping cc's because I think most people don't care about this bit]\n\nOn Thu, Aug 28, 2008 at 04:22:12PM -0700, Perry Wagle wrote:\n\n> What I saw was \"git produces a list of 143 commands. Long \n> lists are inefficient. Get rid of it!\". Actually the list is a hash \n> table in any reasonable shell. So its only aesthetics?\n\nI saw some talk of efficiency, but it was mainly \"100,000 files in one\ndirectory makes your filesystem performance suck\". But maybe somebody\ntalked about the shell. I think there is \"143 is too many, and scares\nnew users\". And I think there is \"systems with hardlink problems ended\nup with 100+ copies of the git binary, which is big\". For the latter,\nyou could still keep git-* with a much smaller wrapper, of course.\n\n> Being able to quickly see the list is very useful. That could be done \n> with git, except some people want that to be lobotomized to \n> show only a fraction of the total. My mind boggles at that one.\n\nI think there is a recognition that some of the commands aren't really\nthat useful to end users, but are kept around as helpers or as scripts.\nFor example, the interactive mode of \"git add\" is implemented in perl\n(while the rest is implemented in C). So it is purely an implementation\nissue that the script git-add--interactive exists. Nobody should be\ncalling it directly, but rather going through \"git add -i\", which will\ncall it as necessary with the right command line options.\n\n> But see my other post. I'm over it.\n\nGood. :)\n\n-Peff\n"},{"id":"89046","messageId":"20080828234151.GG29609@coredump.intra.peff.net","threadId":"15184","inReplyTo":"7vmyiwd8ot.fsf@gitster.siamese.dyndns.org","subject":"git-* in test scripts (was On deprecating \"git-foo\" for builtins)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T23:41:51Z","receivedAt":"2008-08-28T23:41:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:\n\n> Test scripts are executed in a special environment whose GIT_EXEC_PATH\n> points at the top of the build tree, where all git-foo lives.\n\nI am not sure how GIT_EXEC_PATH is relevant. We put the git top-level\ndirectory in the PATH, which is why \"git-foo\" works at all in the test\nscripts. But the install by default does _not_ put those commands in\nthe PATH. So the test scripts serve as a poor example of how to use\ngit. The commands contained within them would not run in an ordinary git\ninstallation.\n\n-Peff\n"},{"id":"89047","messageId":"20080828234506.GA30195@coredump.intra.peff.net","threadId":"15184","inReplyTo":"CD2FC91F-D5BB-486D-B138-F521A493FE73@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-28T23:45:06Z","receivedAt":"2008-08-28T23:45:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 04:14:14PM -0700, Perry Wagle wrote:\n\n> I did:\n>\n> pwagle@starscream:/usr/lib/cgi-bin$ ls -l\n> total 352\n> -rw-r--r-- 1 root root 164 2008-03-07 12:03 git-favicon.png\n> -rw-r--r-- 1 root root 208 2008-03-07 12:03 git-logo.png\n> -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi\n> -rw-r--r-- 1 root root 7112 2008-03-07 12:03 gitweb.css\n> -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl\n> pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l\n> 68\n> pwagle@starscream:/usr/lib/cgi-bin$\n\n1. Your numbers are doubled because gitweb.cgi is the built form of\ngitweb.perl.\n\n2. Look at the grep output. They are all in comments or messages.\nPerhaps the messages should say \"open git diff failed\" instead of \"open\ngit-diff failed\". But the \"git-foo\" form has been kept as a\ntypographical convention because it makes more sense from a language\nperspective (just as you would hyphenate some compound words, or an\nadjective phrase). Perhaps that is a mistake, given the confusion.\n\n-Peff\n"},{"id":"89050","messageId":"928D2C14-23B9-4351-BBB2-234A94980E83@cs.indiana.edu","threadId":"15184","inReplyTo":"20080828234506.GA30195@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Perry Wagle","fromEmail":"wagle@cs.indiana.edu","sentAt":"2008-08-28T23:55:13Z","receivedAt":"2008-08-28T23:55:13Z","isPatch":false,"sender":{"key":"wagle@cs.indiana.edu","avatar":null},"body":"Okay, thanks for the analysis! He pulled a minor remark out and said \nI didn't look, when I had. I have other things to do this week, but \nthis thread is now, so I gotta do the ballpark measurements now (with \nsome hope of reversing a upward compatibility breakage, which isn't \nimportant any more, see my other post). Later I go in and s/git/ \ngit/g in my one-true-editor 8) and see for sure how many I \nactually need to change. Gitweb wasn't my main problem, just one I \nhad to think about when I can sit down and test the upgrade to 1.6.0.\n\n-- Perry\n\n\nOn Aug 28, 2008, at 4:45 PM, Jeff King wrote:\n\n> On Thu, Aug 28, 2008 at 04:14:14PM -0700, Perry Wagle wrote:\n>\n>> I did:\n>>\n>> pwagle@starscream:/usr/lib/cgi-bin$ ls -l\n>> total 352\n>> -rw-r--r-- 1 root root 164 2008-03-07 12:03 git-favicon.png\n>> -rw-r--r-- 1 root root 208 2008-03-07 12:03 git-logo.png\n>> -rwxr-xr-x 1 root root 167729 2008-03-07 12:03 gitweb.cgi\n>> -rw-r--r-- 1 root root 7112 2008-03-07 12:03 gitweb.css\n>> -rwxr-xr-x 1 root root 167932 2008-03-07 12:03 gitweb.perl\n>> pwagle@starscream:/usr/lib/cgi-bin$ grep git- * | wc -l\n>> 68\n>> pwagle@starscream:/usr/lib/cgi-bin$\n>\n> 1. Your numbers are doubled because gitweb.cgi is the built form of\n> gitweb.perl.\n>\n> 2. Look at the grep output. They are all in comments or messages.\n> Perhaps the messages should say \"open git diff failed\" instead of \n> \"open\n> git-diff failed\". But the \"git-foo\" form has been kept as a\n> typographical convention because it makes more sense from a language\n> perspective (just as you would hyphenate some compound words, or an\n> adjective phrase). Perhaps that is a mistake, given the confusion.\n>\n> -Peff\n"},{"id":"89057","messageId":"7v7ia0d6u9.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080828234151.GG29609@coredump.intra.peff.net","subject":"Re: git-* in test scripts","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-08-29T00:04:46Z","receivedAt":"2008-08-29T00:04:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:\n>\n>> Test scripts are executed in a special environment whose GIT_EXEC_PATH\n>> points at the top of the build tree, where all git-foo lives.\n>\n> I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level\n> directory in the PATH, which is why \"git-foo\" works at all in the test\n> scripts. But the install by default does _not_ put those commands in\n> the PATH. So the test scripts serve as a poor example of how to use\n> git. The commands contained within them would not run in an ordinary git\n> installation.\n\nWell, I was merely replying to your message. If you admit that tests are\nspecial and a poor example, why did you bring it up? ;-)\n"},{"id":"89061","messageId":"20080829001029.GB30453@coredump.intra.peff.net","threadId":"15184","inReplyTo":"7v7ia0d6u9.fsf@gitster.siamese.dyndns.org","subject":"Re: git-* in test scripts","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-08-29T00:10:29Z","receivedAt":"2008-08-29T00:10:29Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 28, 2008 at 05:04:46PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > On Thu, Aug 28, 2008 at 04:24:50PM -0700, Junio C Hamano wrote:\n> >\n> >> Test scripts are executed in a special environment whose GIT_EXEC_PATH\n> >> points at the top of the build tree, where all git-foo lives.\n> >\n> > I am not sure how GIT_EXEC_PATH is relevant. We put the git top-level\n> > directory in the PATH, which is why \"git-foo\" works at all in the test\n> > scripts. But the install by default does _not_ put those commands in\n> > the PATH. So the test scripts serve as a poor example of how to use\n> > git. The commands contained within them would not run in an ordinary git\n> > installation.\n> \n> Well, I was merely replying to your message. If you admit that tests are\n> special and a poor example, why did you bring it up? ;-)\n\nI don't quite follow you. I think that the tests are actively being used\nby people to see how they should invoke git, but they are very bad for\nthat, because they are still using the dashed form. So either the people\nshould stop doing that, or the tests should stop using the dashed form.\nI think the latter is much easier for us to control.\n\nI sent a patch for this probably a year ago, but nobody seemed\ninterested. I'm sure it is hopelessly out of date at this point (it was\nnot as easy as a mechanical change because there are other things that\nlook like git-*, like filename arguments to commands).\n\n-Peff\n"},{"id":"89096","messageId":"48B7AA67.4040400@op5.se","threadId":"15184","inReplyTo":"20080828230401.GC29609@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-08-29T07:51:03Z","receivedAt":"2008-08-29T07:51:03Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeff King wrote:\n> On Thu, Aug 28, 2008 at 03:33:26PM -0700, Perry Wagle wrote:\n> \n>> I'm going by the reasoning shown in this thread. Why not? I'm looking \n>> for a way not to have to do exhaustive testing on those scripts, so would \n>> love to hear it.\n> \n> Ultimately you must be the judge of what and how much to test on your\n> systems. But if you are asking if there are other similar compatibility\n> bugs in 1.6.0, then my opinion, as somebody who follows the git list\n> quite closely and contributes some code, is that no, there are not.\n> \n\nThere's one, actually. The default pack-index version is increased now,\nso really, really old clients (pre-1.4.5) won't be able to understand\nthe packs generated by default by a new server. I haven't examined how\nand when this affect clients, although I believe only those using an\nancient client that fetch pre-created packs over dumb transport (http\nor rsync) repo packed with pack.indexversion = 2, or with 1.6.0\nwithout a pack.indexversion setting at all, will suffer.\n\nEncountering that particular scenario should be very rare indeed.\n\nApart from that, I agree with Jeff about there not being any problems\nregarding compatibility, and I wholeheartedly agree with the hint to\nstart reading the releasenotes.\n\nAs for suggesting future improvements, perhaps relnotes entries with\nthe slightest chance of breaking anything for anyone could be marked\n\"COMPAT\" or something, so Perry and the likes of him can find them\neasily. I also agree with the suggestion that git itself should be\nfree of a deprecated way of doing things at the deprecation date.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"89097","messageId":"vpqvdxk5jrl.fsf@bauges.imag.fr","threadId":"15184","inReplyTo":"48B7AA67.4040400@op5.se","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-08-29T08:05:02Z","receivedAt":"2008-08-29T08:05:02Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Andreas Ericsson writes:\n\n> There's one, actually. The default pack-index version is increased now,\n> so really, really old clients (pre-1.4.5) won't be able to understand\n> the packs generated by default by a new server.\n\nAAUI, the pack itself is sent over the network, but the index is\ngenerated locally when receiving the pack, so this shouldn't be a\nproblem.\n\n-- \nMatthieu\n"},{"id":"89100","messageId":"48B7B20F.9030208@op5.se","threadId":"15184","inReplyTo":"vpqvdxk5jrl.fsf@bauges.imag.fr","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-08-29T08:23:43Z","receivedAt":"2008-08-29T08:23:43Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Matthieu Moy wrote:\n> Andreas Ericsson writes:\n> \n>> There's one, actually. The default pack-index version is increased now,\n>> so really, really old clients (pre-1.4.5) won't be able to understand\n>> the packs generated by default by a new server.\n> \n> AAUI, the pack itself is sent over the network, but the index is\n> generated locally when receiving the pack, so this shouldn't be a\n> problem.\n> \n\nWhich is why I later in the same message pointed out that this should\nonly happen when using dumb protocols where the pack isn't reindexed\nafter it has been fetched.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"89102","messageId":"1f6632e50808290127x2ec1ee6am90639b35aba5b764@mail.gmail.com","threadId":"15184","inReplyTo":"vpqvdxk5jrl.fsf@bauges.imag.fr","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthias Kestenholz","fromEmail":"mk@spinlock.ch","sentAt":"2008-08-29T08:27:08Z","receivedAt":"2008-08-29T08:27:08Z","isPatch":false,"sender":{"key":"matthias@spinlock.ch","avatar":"https://gravatar.com/avatar/bc18f396e70163d09ab458a341b1decb7e8b6ee3aa2c0c954ec20162e67c4d46?d=mp&s=160"},"body":"On Fri, Aug 29, 2008 at 10:05 AM, Matthieu Moy wrote:\n> Andreas Ericsson writes:\n>\n>> There's one, actually. The default pack-index version is increased now,\n>> so really, really old clients (pre-1.4.5) won't be able to understand\n>> the packs generated by default by a new server.\n>\n> AAUI, the pack itself is sent over the network, but the index is\n> generated locally when receiving the pack, so this shouldn't be a\n> problem.\n>\n\nIf you use the git or ssh protocol, then yes. If you use dumb protocols such as\nHTTP or rsync, no.\n\nMatthias\n"},{"id":"89106","messageId":"vpqhc945h31.fsf@bauges.imag.fr","threadId":"15184","inReplyTo":"1f6632e50808290127x2ec1ee6am90639b35aba5b764@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2008-08-29T09:02:58Z","receivedAt":"2008-08-29T09:02:58Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"\"Matthias Kestenholz\" writes:\n\n>> AAUI, the pack itself is sent over the network, but the index is\n>> generated locally when receiving the pack, so this shouldn't be a\n>> problem.\n>\n> If you use the git or ssh protocol, then yes. If you use dumb protocols such as\n> HTTP or rsync, no.\n\nThanks for the clarification, and sorry for the noise then ;-).\n\n-- \nMatthieu\n"},{"id":"89110","messageId":"06844986-44BF-4B82-A45F-0781B3513409@wincent.com","threadId":"15184","inReplyTo":"20080828212346.GA27867@coredump.intra.peff.net","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-08-29T09:33:58Z","receivedAt":"2008-08-29T09:33:58Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 28/8/2008, a las 23:23, Jeff King escribió:\n\n> I don't think Junio is declaring success. In fact, I think he has sent\n> several messages saying (paraphrasing of course):\n>\n> - this was obviously not done in the best manner possible, because of\n> the number of people complaining\n\nOne thing we mustn't lose sight of is that the number of people \ncomplaining is that it is utterly insignificant compared to the \nseething hordes that have complained about the number of git- commands \nin /usr/bin over the years. We're talking about a dozen or so compared \nto hundreds. And the change is likely to save us from hundreds more in \nthe future.\n\nCheers,\nWincent\n"},{"id":"89094","messageId":"94a0d4530808290712s2044dd03pb93cb4a829dc56b0@mail.gmail.com","threadId":"15184","inReplyTo":"alpine.LFD.1.10.0808280936300.3300@nehalem.linux-foundation.org","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-29T14:12:58Z","receivedAt":"2008-08-29T14:12:58Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Thu, Aug 28, 2008 at 7:37 PM, Linus Torvalds\n wrote:\n>\n>\n> On Thu, 28 Aug 2008, Felipe Contreras wrote:\n>>\n>> If the git-foo was supposed to be deprecated in 1.6.0\n>\n> Itw as deprecated over a _year_ ago.\n>\n>> When it becomes truly obsolete, then people can rely on git exec-dir,\n>> which will be disabled by default.\n>\n> It _is_ obsolete, but there's a trivial compatibility thing.\n>\n> Are you happy now? How hard is it to really understand?\n\nIt only takes one word; obsolete. I haven't heard that git-foo is\nobsolete until now, all I heard is that it was deprecated. Maybe I\nshould have paid more attention but that's not the point.\n\nWhat other projects do is make very visible when something is\ndeprecated, like a big, annoying, unbearable warning. Next time you\ndeprecated a command it might be a good idea to add the warning each\ntime the command is used, and obsolete it later on.\n\nAlso, if it's a big change like this git- stuff, then do a major version bump.\n\nIf you had marked 1.6 as 2.0, and added warnings when you deprecated\nthe git-foo stuff then the users would have no excuse. It would have\nbeen obvious and this huge thread would have been avoided.\n\nPersonally I'm subscribed to the mailing and I read the release notes\nof 1.6, but I didn't register that change. I install my git stuff to\n/opt/git, so when I was using git-foo I was using the old commands\nthat come from Fedora. It wasn't until I read this thread that I\nnoticed.\n\nDon't expect users to be a aware of what's happening on the project,\nmany wouldn't even notice that there was a minor version bump. Julio,\nI guess that recommendation goes for you.\n\nBest regards.\n\n-- \nFelipe Contreras\n"},{"id":"89137","messageId":"20080829152451.GA20629@yugib.highrise.ca","threadId":"15184","inReplyTo":"881C17DA-2FE2-49A7-A4A9-FACA7720599C@cs.indiana.edu","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2008-08-29T15:24:51Z","receivedAt":"2008-08-29T15:24:51Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"* Perry Wagle [080801 00:00]:\n> Jeff King has convinced me that it's perfectly legitimate to introduce \n> non-upward compatibilities in minor version releases of \"young\" \n> software.\n\nThis is the gist of the problem. You keep hammering about a\n\"non-upwards compatibilities in minor version releases\", yet you have\n*not* pointed out one such in-compatibility in a minor version release..\n\nRemember, in git, 1.6 is a \"major version\" release, with release notes, etc.\n1.5.X is a \"minor version\" release.\n1.5.X.Y is a \"patch\" release.\n\nIt's a pretty normal versioning scheme.\n\nGit 1.5.X -> Git 1.6.X is a major release upgrade. And the Git 1.5\nrelease notes have claimed for a while that git- executibles are\ngoing to be moved out of the default path for a while. And the Git 1.6\nrelease notes claimed they were...\n\n*And* git developpers have admitted that communication about that\npending change was obviously insufficient...\n\nBut that's a hard problem...\n\nHow do developers make sure that users are reading release notes?\n*Especially* in a world where software is packaged up by\nsystems/distros/etc. It's a problem that hits software across the\nboard, linux kernel, PostgreSQL, glibc, gcc, X.org, HylaFAX, and yes,\ngit.\n\nGit 1.5.4 has had the \"git-exec-dir in path\" deprecated for months. How\ncan we do a better job of letting *users* know of the documented stuff\nin the release notes?\n\nCan you imagine the outcry if git was made to look for the config value\ncore.hasreadreleasenotes. on every invocation, and if it wasn't\nset, forced the releasenotes throught the pager? That way, you woudl\nhave known 6 months ago that git had published release-notes saying that\ngit-exec-dir change was going to happen...\n\n-- \nAidan Van Dyk Create like a god,\naidan@highrise.ca command like a king,\nhttp://www.highrise.ca/ work like a slave.\n"},{"id":"89139","messageId":"94a0d4530808290911j32bf5ee0q869dfe39483297f8@mail.gmail.com","threadId":"15184","inReplyTo":"20080829152451.GA20629@yugib.highrise.ca","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-29T16:11:26Z","receivedAt":"2008-08-29T16:11:26Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk wrote:\n> * Perry Wagle [080801 00:00]:\n>> Jeff King has convinced me that it's perfectly legitimate to introduce\n>> non-upward compatibilities in minor version releases of \"young\"\n>> software.\n>\n> This is the gist of the problem. You keep hammering about a\n> \"non-upwards compatibilities in minor version releases\", yet you have\n> *not* pointed out one such in-compatibility in a minor version release..\n>\n> Remember, in git, 1.6 is a \"major version\" release, with release notes, etc.\n> 1.5.X is a \"minor version\" release.\n> 1.5.X.Y is a \"patch\" release.\n\nWhat is X (2.0)?\n\n-- \nFelipe Contreras\n"},{"id":"89141","messageId":"20080829162420.GB20629@yugib.highrise.ca","threadId":"15184","inReplyTo":"94a0d4530808290911j32bf5ee0q869dfe39483297f8@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2008-08-29T16:24:20Z","receivedAt":"2008-08-29T16:24:20Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"* Felipe Contreras [080829 12:11]:\n> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk wrote:\n> > * Perry Wagle [080801 00:00]:\n> >> Jeff King has convinced me that it's perfectly legitimate to introduce\n> >> non-upward compatibilities in minor version releases of \"young\"\n> >> software.\n> >\n> > This is the gist of the problem. You keep hammering about a\n> > \"non-upwards compatibilities in minor version releases\", yet you have\n> > *not* pointed out one such in-compatibility in a minor version release..\n> >\n> > Remember, in git, 1.6 is a \"major version\" release, with release notes, etc.\n> > 1.5.X is a \"minor version\" release.\n> > 1.5.X.Y is a \"patch\" release.\n> \n> What is X (2.0)?\n\nX would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git\n1.5 releases:\n\t1.5.0\n\t1.5.1\n\t1.5.2\n\t1.5.3\n\t1.5.4\n\t1.5.4\n\t1.5.6\n\nAnd now also:\n\t1.6.0, being the first of the 1.6 releases...\n\na.\n-- \nAidan Van Dyk Create like a god,\naidan@highrise.ca command like a king,\nhttp://www.highrise.ca/ work like a slave.\n"},{"id":"89142","messageId":"94a0d4530808290928w3b1decd4o2e77349d793ffff0@mail.gmail.com","threadId":"15184","inReplyTo":"20080829162420.GB20629@yugib.highrise.ca","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2008-08-29T16:28:39Z","receivedAt":"2008-08-29T16:28:39Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk wrote:\n> * Felipe Contreras [080829 12:11]:\n>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk wrote:\n>> > * Perry Wagle [080801 00:00]:\n>> >> Jeff King has convinced me that it's perfectly legitimate to introduce\n>> >> non-upward compatibilities in minor version releases of \"young\"\n>> >> software.\n>> >\n>> > This is the gist of the problem. You keep hammering about a\n>> > \"non-upwards compatibilities in minor version releases\", yet you have\n>> > *not* pointed out one such in-compatibility in a minor version release..\n>> >\n>> > Remember, in git, 1.6 is a \"major version\" release, with release notes, etc.\n>> > 1.5.X is a \"minor version\" release.\n>> > 1.5.X.Y is a \"patch\" release.\n>>\n>> What is X (2.0)?\n>\n> X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git\n> 1.5 releases:\n> 1.5.0\n> 1.5.1\n> 1.5.2\n> 1.5.3\n> 1.5.4\n> 1.5.4\n> 1.5.6\n>\n> And now also:\n> 1.6.0, being the first of the 1.6 releases...\n\nI meant 'X.0.0', if 1.X is major, what is X.0? Huge?\n\n-- \nFelipe Contreras\n"},{"id":"89143","messageId":"20080829164121.GC20629@yugib.highrise.ca","threadId":"15184","inReplyTo":"94a0d4530808290928w3b1decd4o2e77349d793ffff0@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Aidan Van Dyk","fromEmail":"aidan@highrise.ca","sentAt":"2008-08-29T16:41:21Z","receivedAt":"2008-08-29T16:41:21Z","isPatch":false,"sender":{"key":"aidan@highrise.ca","avatar":"https://gravatar.com/avatar/853c50d90cce753dc1c390fdc6cbed558f5f969bd43fa4f5cb0118d8f71316f6?d=mp&s=160"},"body":"* Felipe Contreras [080829 12:28]:\n \n> I meant 'X.0.0', if 1.X is major, what is X.0? Huge?\n\nBackwards compatible?\n\n;-)\n\n-- \nAidan Van Dyk Create like a god,\naidan@highrise.ca command like a king,\nhttp://www.highrise.ca/ work like a slave.\n"},{"id":"89191","messageId":"48B9013A.70201@op5.se","threadId":"15184","inReplyTo":"94a0d4530808290928w3b1decd4o2e77349d793ffff0@mail.gmail.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-08-30T08:13:46Z","receivedAt":"2008-08-30T08:13:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Felipe Contreras wrote:\n> On Fri, Aug 29, 2008 at 7:24 PM, Aidan Van Dyk wrote:\n>> * Felipe Contreras [080829 12:11]:\n>>> On Fri, Aug 29, 2008 at 6:24 PM, Aidan Van Dyk wrote:\n>>>> * Perry Wagle [080801 00:00]:\n>>>>> Jeff King has convinced me that it's perfectly legitimate to introduce\n>>>>> non-upward compatibilities in minor version releases of \"young\"\n>>>>> software.\n>>>> This is the gist of the problem. You keep hammering about a\n>>>> \"non-upwards compatibilities in minor version releases\", yet you have\n>>>> *not* pointed out one such in-compatibility in a minor version release..\n>>>>\n>>>> Remember, in git, 1.6 is a \"major version\" release, with release notes, etc.\n>>>> 1.5.X is a \"minor version\" release.\n>>>> 1.5.X.Y is a \"patch\" release.\n>>> What is X (2.0)?\n>> X would be a digit, like 0, 1, 2, 3, 4, 5, 6, 7, 8, or 9, as in the git\n>> 1.5 releases:\n>> 1.5.0\n>> 1.5.1\n>> 1.5.2\n>> 1.5.3\n>> 1.5.4\n>> 1.5.4\n>> 1.5.6\n>>\n>> And now also:\n>> 1.6.0, being the first of the 1.6 releases...\n> \n> I meant 'X.0.0', if 1.X is major, what is X.0? Huge?\n> \n\nX.0 is \"technically backwards incompatible\".\n\nIf, for example, SHA1 turns out to be horribly broken, git might have\nto be updated to use something else instead. Such a switch would\nrequire a version bump from 1.x to 2.x.\n\nThat might come some day anyway, assuming we decide to make a flag-day\nand just remove older-version compatibility code from git or some\nsuch.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"89209","messageId":"alpine.DEB.1.10.0808300916510.28765@gandalf.stny.rr.com","threadId":"15184","inReplyTo":"06844986-44BF-4B82-A45F-0781B3513409@wincent.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2008-08-30T13:24:26Z","receivedAt":"2008-08-30T13:24:26Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"\nOn Fri, 29 Aug 2008, Wincent Colaiuta wrote:\n\n> El 28/8/2008, a las 23:23, Jeff King escribi?:\n> \n> > I don't think Junio is declaring success. In fact, I think he has sent\n> > several messages saying (paraphrasing of course):\n> > \n> > - this was obviously not done in the best manner possible, because of\n> > the number of people complaining\n> \n> One thing we mustn't lose sight of is that the number of people complaining is\n> that it is utterly insignificant compared to the seething hordes that have\n> complained about the number of git- commands in /usr/bin over the years. We're\n> talking about a dozen or so compared to hundreds. And the change is likely to\n> save us from hundreds more in the future.\n\nI have to admit, the first time I saw the git- result, my first \nreaction was WTF! But given time, I became use to it, and actually \n_preferred_ the dash version.\n\nSo I belonged to both camps. I complained about all the dash options, and \nI also complained about the dash options going away ;-)\n\nGrant you, my complaints were not loud, I just utter some grumbles to git \ndevelopers that I knew.\n\nLets not look at the number of complaints, but the level each complaint \nis. My first reaction to the git- was more of a shock than \nanything else. So my complaint was very short lived, like someone cutting \nme off on the highway.\n\nBut after getting use to the dash version, and having that go away, makes \nme need to retrain myself to do things another way. This feels more like \nlosing a pet, and complaining about that. This is a much more painful \nchange than having to live with hordes of git commands.\n\n-- Steve\n"},{"id":"89210","messageId":"20080830135012.GA3124@mithlond.arda.local","threadId":"15184","inReplyTo":"alpine.DEB.1.10.0808300916510.28765@gandalf.stny.rr.com","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-08-30T13:50:12Z","receivedAt":"2008-08-30T13:50:12Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Steven Rostedt wrote (2008-08-30 09:24 -0400):\n\n> But after getting use to the dash version, and having that go away,\n> makes me need to retrain myself to do things another way. This feels\n> more like losing a pet, and complaining about that. This is a much\n> more painful change than having to live with hordes of git commands.\n\nDon't worry, you didn't lose your pet. You have actually two pets now \nand it has become easier to play with both of them. Just shout\n\n PATH=\"$PATH:$(git --exec-path)\"\n\nand the older pet will come. However, it's preferred that you mostly \nshow the new one to your neighbours.\n\n:-)\n"},{"id":"89211","messageId":"alpine.DEB.1.10.0808301004010.28765@gandalf.stny.rr.com","threadId":"15184","inReplyTo":"20080830135012.GA3124@mithlond.arda.local","subject":"Re: [kernel.org users] [RFD] On deprecating \"git-foo\" for builtins","fromName":"Steven Rostedt","fromEmail":"rostedt@goodmis.org","sentAt":"2008-08-30T14:08:24Z","receivedAt":"2008-08-30T14:08:24Z","isPatch":false,"sender":{"key":"rostedt@goodmis.org","avatar":"https://gravatar.com/avatar/cc188bf330d625ec6a7a2d0b6f4829dc777963e8dab83d943691dc31c5095227?d=mp&s=160"},"body":"\n\nOn Sat, 30 Aug 2008, Teemu Likonen wrote:\n\n> Steven Rostedt wrote (2008-08-30 09:24 -0400):\n> \n> > But after getting use to the dash version, and having that go away,\n> > makes me need to retrain myself to do things another way. This feels\n> > more like losing a pet, and complaining about that. This is a much\n> > more painful change than having to live with hordes of git commands.\n> \n> Don't worry, you didn't lose your pet. You have actually two pets now \n> and it has become easier to play with both of them. Just shout\n> \n> PATH=\"$PATH:$(git --exec-path)\"\n> \n> and the older pet will come. However, it's preferred that you mostly \n> show the new one to your neighbours.\n\nHeh, yeah, I saw this. I was just letting people know that the number of \ncomplaints do not always measure the level people are complaining about.\n\nThe complaint I did about seeing the 140 git-* commands was more of a \nknee-jerk reaction, as suppose to the complaint about git-* going away, \nwhich would have been something that would affect me every time I hit '-'. \n\nRemember, before Linus stated that the 'git --exec-path' is not going to \nbe deprecated, that was soon to disappear too.\n\n-- Steve\n"},{"id":"89660","messageId":"20080903175651.GZ10360@machine.or.cz","threadId":"15184","inReplyTo":"m3y72jr80w.fsf@localhost.localdomain","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-03T17:56:51Z","receivedAt":"2008-09-03T17:56:51Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 26, 2008 at 10:38:45AM -0700, Jakub Narebski wrote:\n> Petr Baudis writes:\n> > +\t\tcount-objects) : plumbing;;\n> \n> Plumbing (hyphenated name is a very good hint), but useful to decide\n> when to repack. I'm partially to leaving it, as I use it from time to\n> time from CLI.\n\nIs this just residuum of customs developed before auto-gc was\nintroduced?\n\n> > +\t\tls-files) : plumbing;;\n> \n> IIRC it doesn't have porcelain equivalent.\n\ngit status for the generally end-user-interesting functionality.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"89697","messageId":"20080903222350.GC10360@machine.or.cz","threadId":"15184","inReplyTo":"7v1w0bab1c.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-03T22:23:50Z","receivedAt":"2008-09-03T22:23:50Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Aug 26, 2008 at 11:25:35AM -0700, Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > Petr Baudis wrote:\n> >> git still shows way too many commands, some of them\n> >> are clearly plumbing. This patch hides the plumbing commands\n> >> liberally (that is, in special cases, users still might want to\n> >> call one of the hidden commands, a *normal* workflow should never\n> >> involve these, though - and if it does, we have a UI problem anyway).\n> >> \n> >> Signed-off-by: Petr Baudis \n> >\n> > Acked-by: Shawn O. Pearce \n> >\n> > Though I use git ls-remote at least once every other day to see\n> > what branches are available on my egit/spearce.git fork. Its ok,\n> > I guess I can type a few extra characters...\n> \n> Revision-requested-by: me\n> \n> Unless/until we have an easy way to obtain the information \"git-ls-files\n> -u\" gives during conflict resolution, ls-files should stay on the list of\n> commonly used commands.\n\nI started on a patch, but frankly, I hate it. Adding such a filtering to\ngit-status is quite invasive, while I believe that it's simply not worth\nit - I have yet to encounter a situation with git when simply looking at\neither git diff or plain git status is impractical to check which files\nneed to be merged yet, so I don't want to expend energy on a patch which\nis going to be ugly and useless by my belief.\n\nIf you do insist that we need this functionality, can you please just\ndrop the git ls-files bit from the patch, or should I resend it?\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nThe next generation of interesting software will be done\non the Macintosh, not the IBM PC. -- Bill Gates\n"},{"id":"89699","messageId":"20080903223118.GW10544@machine.or.cz","threadId":"15184","inReplyTo":"20080903222350.GC10360@machine.or.cz","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2008-09-03T22:31:18Z","receivedAt":"2008-09-03T22:31:18Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Sep 04, 2008 at 12:23:50AM +0200, Petr Baudis wrote:\n> I started on a patch, but frankly, I hate it. Adding such a filtering to\n> git-status is quite invasive, while I believe that it's simply not worth\n> it - I have yet to encounter a situation with git when simply looking at\n> either git diff or plain git status is impractical to check which files\n> need to be merged yet, so I don't want to expend energy on a patch which\n> is going to be ugly and useless by my belief.\n> \n> If you do insist that we need this functionality, can you please just\n> drop the git ls-files bit from the patch, or should I resend it?\n\nIt just occured to me - what about\n\n\tgit diff --diff-filter=U [--name-status]\n\nor is that too long? (The universal answer being, \"you can alias it\".\n;-)\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"89725","messageId":"7vwshs7bjo.fsf@gitster.siamese.dyndns.org","threadId":"15184","inReplyTo":"20080903175651.GZ10360@machine.or.cz","subject":"Re: [PATCH] bash completion: Hide more plumbing commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-09-04T04:57:47Z","receivedAt":"2008-09-04T04:57:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Tue, Aug 26, 2008 at 10:38:45AM -0700, Jakub Narebski wrote:\n>> Petr Baudis writes:\n>> > +\t\tcount-objects) : plumbing;;\n>> \n>> Plumbing (hyphenated name is a very good hint), but useful to decide\n>> when to repack. I'm partially to leaving it, as I use it from time to\n>> time from CLI.\n>\n> Is this just residuum of customs developed before auto-gc was\n> introduced?\n>\n>> > +\t\tls-files) : plumbing;;\n>> \n>> IIRC it doesn't have porcelain equivalent.\n>\n> git status for the generally end-user-interesting functionality.\n\nI do not consider either of the above plumbing, but I tend to agree that\nthey are much less frequently used. I think verify-pack falls into the\nsame category.\n\nApplied to 'maint' but won't be pushing out for some time (my git day is\nover).\n"}]}