{"thread":{"id":"10307","subject":"On Tabs and Spaces","startedAt":"2007-10-16T06:45:47Z","lastAt":"2007-10-22T03:39:39Z","messageCount":100,"participants":["Michael Witten","Shawn O. Pearce","Adam Piatyszek","Lars Hjemli","Jeffrey C. Ollie","Andreas Ericsson","Sam Ravnborg","Jari Aalto","Jan-Benedict Glaw","Linus Torvalds","Mike Hommey","Tom Tobin","Matthieu Moy","Petr Baudis","Christer Weinigel","David","David Kastrup","Luke Lu","Nikolai Weibull","Andy Parkins","Nicolas Pitre","Sean","Johannes Schindelin","Jan Wielemaker","Josh England","Jeff King","david@lang.hm","Paul Wankadia","Dmitry Torokhov","Dmitry Potapov","koreth@midwinter.com","Steven Grimm","David Kågedal","Brian Gernhardt","Robin Rosenberg","Miles Bader"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55964","messageId":"634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu","threadId":"10307","inReplyTo":null,"subject":"On Tabs and Spaces","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-16T06:45:47Z","receivedAt":"2007-10-16T06:45:47Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"What are the rules about tabs and spaces in source code?\n\nI'm having a terrible time with formatting,\nespecially in the perl scripts; there is a\nmix of spaces and tabs.\n\nfrom what I can deduce, single tabs are used\nto introduce the equivalent of 8 spaces while\n4 explicit spaces are used for half a tab.\n\nI would recommend using all spaces, but the C\ncode seems to prefer all tabs.\n\nIn any case, some kind of standards need to be\nset, because no one is following anything curr-\nently.\n\nSincerely,\nMichael Witten\n"},{"id":"55966","messageId":"20071016070421.GE13801@spearce.org","threadId":"10307","inReplyTo":"634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-16T07:04:21Z","receivedAt":"2007-10-16T07:04:21Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Michael Witten wrote:\n> What are the rules about tabs and spaces in source code?\n> \n> I'm having a terrible time with formatting,\n> especially in the perl scripts; there is a\n> mix of spaces and tabs.\n> \n> from what I can deduce, single tabs are used\n> to introduce the equivalent of 8 spaces while\n> 4 explicit spaces are used for half a tab.\n\nThe C code is all tabs, with the tabs set at 8 spaces, but the\nactual tab width isn't too important here as we never use the tab\nfor alignment beyond the left indent.\n\nThe bulk of the Perl/shell is also done that way, but you may\nrun into a place where it isn't. In which case try to match the\nexisting identation within that block as best as you can so the diff\nis minimal and the resulting file still indents just as good/bad\nas it did before.\n\nYou may also consider submitting a whitespace correction patch in\nfront of your actual code change to correct the offending part of\nthe file, but every line you touch is that much more work for your\npeers to review and test. In short changing code is bad unless\nthere is a really compelling reason...\n\n-- \nShawn.\n"},{"id":"55971","messageId":"11F85069-1013-4685-9D56-C53F0F8231BF@MIT.EDU","threadId":"10307","inReplyTo":"20071016070421.GE13801@spearce.org","subject":"Re: On Tabs and Spaces","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-16T07:27:18Z","receivedAt":"2007-10-16T07:27:18Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote:\n\n> The C code is all tabs, with the tabs set at 8 spaces, but the\n> actual tab width isn't too important here as we never use the tab\n> for alignment beyond the left indent.\n\nConsider this from diff-lib.c:\n\n> /* A file entry went away or appeared */\n> static void diff_index_show_file(struct rev_info *revs,\n> \t\t\t\t const char *prefix,\n> \t\t\t\t struct cache_entry *ce,\n> \t\t\t\t unsigned char *sha1, unsigned int mode)\n> {\n> \tdiff_addremove(&revs->diffopt, prefix[0], ntohl(mode),\n> \t\t sha1, ce->name, NULL);\n> }\n\nThere are mixed tabs and spaces for alignment.\n\nI suppose I'll be fine if I just set tab widths to 8.\nBut 8 spaces! Good Lord. ;-)\n\nI really hate tabs.\n\nThanks,\nMichael Witten\n"},{"id":"55986","messageId":"471476B7.5050105@users.sourceforge.net","threadId":"10307","inReplyTo":"634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2007-10-16T08:30:47Z","receivedAt":"2007-10-16T08:30:47Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Michael Witten [16 X 2007 08:45]:\n> What are the rules about tabs and spaces in source code?\n\nFollowing this topic, I am kindly asking for some tips on configuring\nEmacs and Vim to follow the rules used for Git and kernel code\nindentation/alignment.\nThanks in advance!\n\nBR,\n/Adam\n\n\n-- \n.:. Adam Piatyszek - \"ediap\" .:. JID: ediap(at)jabber.org .:.\n.:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.\n"},{"id":"55992","messageId":"8c5c35580710160204s5a4f9fb3j68c0a86c4d080cb7@mail.gmail.com","threadId":"10307","inReplyTo":"471476B7.5050105@users.sourceforge.net","subject":"Re: On Tabs and Spaces","fromName":"Lars Hjemli","fromEmail":"lh@elementstorage.no","sentAt":"2007-10-16T09:04:47Z","receivedAt":"2007-10-16T09:04:47Z","isPatch":false,"sender":{"key":"lh@elementstorage.no","avatar":null},"body":"On 10/16/07, Adam Piatyszek wrote:\n> I am kindly asking for some tips on configuring\n> Emacs and Vim to follow the rules used for Git and kernel code\n> indentation/alignment.\n\n>From http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle;h=7f1730f1a1ae2e9a6f368bdb10ff65f4568863d5;hb=HEAD\n\n(defun linux-c-mode ()\n \"C mode with adjusted defaults for use with the Linux kernel.\"\n (interactive)\n (c-mode)\n (c-set-style \"K&R\")\n (setq tab-width 8)\n (setq indent-tabs-mode t)\n (setq c-basic-offset 8))\n\n\nAnd to use this only in a specific directory:\n\n(setq auto-mode-alist (cons '(\"/usr/src/linux.*/.*\\\\.[ch]$\" . linux-c-mode)\n\tauto-mode-alist))\n\n--\nlarsh\n"},{"id":"56008","messageId":"47148F72.1090602@users.sourceforge.net","threadId":"10307","inReplyTo":"8c5c35580710160204s5a4f9fb3j68c0a86c4d080cb7@mail.gmail.com","subject":"Re: On Tabs and Spaces","fromName":"Adam Piatyszek","fromEmail":"ediap@users.sourceforge.net","sentAt":"2007-10-16T10:16:18Z","receivedAt":"2007-10-16T10:16:18Z","isPatch":false,"sender":{"key":"ediap@users.sourceforge.net","avatar":null},"body":"* Lars Hjemli [16 X 2007 11:04]:\n>>From http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle;h=7f1730f1a1ae2e9a6f368bdb10ff65f4568863d5;hb=HEAD\n> \n> (defun linux-c-mode ()\n> \"C mode with adjusted defaults for use with the Linux kernel.\"\n> (interactive)\n> (c-mode)\n> (c-set-style \"K&R\")\n> (setq tab-width 8)\n> (setq indent-tabs-mode t)\n> (setq c-basic-offset 8))\n> \n> \n> And to use this only in a specific directory:\n> \n> (setq auto-mode-alist (cons '(\"/usr/src/linux.*/.*\\\\.[ch]$\" . linux-c-mode)\n> \tauto-mode-alist))\n\nThanks!\n\nBut it seems that the above settings are still imperfect, since they\nmixes tabs and spaces when aligning. For instance:\n\nint some_function(int some_variable)\n{\n\tint result;\n\tresult = execute_another_function(some_variable,\n\t\t\t\t\t..other_variable);\n\treturn result;\n}\n\n - represents tab here, `.' - space\n\nAnd if one change the tab size, it will result in a messy alignment in\nline 5.\nI guess there is no ideal solution for this in Emacs.\n\nBR,\n/Adam\n\n\n-- \n.:. Adam Piatyszek - \"ediap\" .:. JID: ediap(at)jabber.org .:.\n.:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:.\n"},{"id":"56068","messageId":"1192548367.3821.4.camel@lt21223.campus.dmacc.edu","threadId":"10307","inReplyTo":"47148F72.1090602@users.sourceforge.net","subject":"Re: On Tabs and Spaces","fromName":"Jeffrey C. Ollie","fromEmail":"jeff@ocjtech.us","sentAt":"2007-10-16T15:26:07Z","receivedAt":"2007-10-16T15:26:07Z","isPatch":false,"sender":{"key":"jeff@ocjtech.us","avatar":"https://gravatar.com/avatar/95918a1992f277a811c471ae7275f7e4c9d1a2e517ad290bd6aa93b97e8d34f3?d=mp&s=160"},"body":"On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:\n> \n> And if one change the tab size, it will result in a messy alignment in\n> line 5.\n\nWhich is why one should never should change the tab size from anything\nbut 8.\n\n> I guess there is no ideal solution for this in Emacs.\n\nInstead of using \"(setq indent-tabs-mode t)\" use \"(setq indent-tabs-mode\nnil)\". This will force emacs to always use spaces to indent.\n\nJeff\n\n"},{"id":"56069","messageId":"B2F6DB0C-4EFE-4C56-8E7A-31820320CA02@mit.edu","threadId":"10307","inReplyTo":"1192548367.3821.4.camel@lt21223.campus.dmacc.edu","subject":"Re: On Tabs and Spaces","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-16T15:51:55Z","receivedAt":"2007-10-16T15:51:55Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote:\n\n> Instead of using \"(setq indent-tabs-mode t)\" use \"(setq indent-tabs- \n> mode\n> nil)\". This will force emacs to always use spaces to indent.\n\nThat's part of the problem to begin with:\npeople are using both way of indentation.\n\nI suggest this not be allowed, or that it\nbe the only way of indenting.\n\nHowever, 8 spaces per tab is a lot of wasted\ninformation to be bandying about.\n\nMichael Witten\n"},{"id":"56105","messageId":"3awb7zw6.fsf@blue.sea.net","threadId":"10307","inReplyTo":"B2F6DB0C-4EFE-4C56-8E7A-31820320CA02@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-10-16T17:06:17Z","receivedAt":"2007-10-16T17:06:17Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Tue 2007-10-16 Michael Witten \n* Message-Id: B2F6DB0C-4EFE-4C56-8E7A-31820320CA02 AT mit.edu\n> On 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote:\n>\n>> Instead of using \"(setq indent-tabs-mode t)\" use \"(setq indent-tabs-\n>> mode\n>> nil)\". This will force emacs to always use spaces to indent.\n>\n> However, 8 spaces per tab is a lot of wasted\n> information to be bandying about.\n\nSpaces are guaranteed to interpreted correctly in all environments. TABs\nare the source of too many problems.\n\nJari\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"56095","messageId":"4714F2CA.5000509@op5.se","threadId":"10307","inReplyTo":"11F85069-1013-4685-9D56-C53F0F8231BF@MIT.EDU","subject":"Re: On Tabs and Spaces","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T17:20:10Z","receivedAt":"2007-10-16T17:20:10Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Michael Witten wrote:\n> On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote:\n> \n>> The C code is all tabs, with the tabs set at 8 spaces, but the\n>> actual tab width isn't too important here as we never use the tab\n>> for alignment beyond the left indent.\n> \n> Consider this from diff-lib.c:\n> \n>> /* A file entry went away or appeared */\n>> static void diff_index_show_file(struct rev_info *revs,\n>> const char *prefix,\n>> struct cache_entry *ce,\n>> unsigned char *sha1, unsigned int mode)\n>> {\n>> diff_addremove(&revs->diffopt, prefix[0], ntohl(mode),\n>> sha1, ce->name, NULL);\n>> }\n> \n> There are mixed tabs and spaces for alignment.\n> \n\nFunction declarations don't count ;-)\n\n> I suppose I'll be fine if I just set tab widths to 8.\n> But 8 spaces! Good Lord. ;-)\n> \n> I really hate tabs.\n> \n\nWell, using hard tabs is the only way we can let everyone have\ndifferent levels of indentation while still having things look\nsort of sane.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56097","messageId":"4714F3A2.3080103@op5.se","threadId":"10307","inReplyTo":"1192548367.3821.4.camel@lt21223.campus.dmacc.edu","subject":"Re: On Tabs and Spaces","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T17:23:46Z","receivedAt":"2007-10-16T17:23:46Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jeffrey C. Ollie wrote:\n> On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:\n>> And if one change the tab size, it will result in a messy alignment in\n>> line 5.\n> \n> Which is why one should never should change the tab size from anything\n> but 8.\n> \n\nI have mine set to 4. With an 11.2\" screen and 1024x768 resolution, it's\nnot as if I've got much choice if I want to be able to see anything on\nthe screen. Some whitespace-damaged places look ugly, but it's usually\nnot too bad.\n\n>> I guess there is no ideal solution for this in Emacs.\n> \n> Instead of using \"(setq indent-tabs-mode t)\" use \"(setq indent-tabs-mode\n> nil)\". This will force emacs to always use spaces to indent.\n> \n\n... but don't do this when hacking on Linux or git. Thanks\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56100","messageId":"20071016174026.GA506@uranus.ravnborg.org","threadId":"10307","inReplyTo":"4714F2CA.5000509@op5.se","subject":"Re: On Tabs and Spaces","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2007-10-16T17:40:26Z","receivedAt":"2007-10-16T17:40:26Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"General comment about the versus spaces debate.\n\nThe root problem is stupid editors that does not show when a tab is used\nand when spaces are used.\nSo people continue to mix tabs and spaces.\n\nIn linux people generally think that 8 aligned spaces equal a tab\nwhich is IMHO stupid.\nTabs should be used for indent and not general alignment.\n\nConsider:\nif (some long condition that\n....&& spans two lines) {\nmy_private_printf(\"bla bla bla\"\n..................\"more bla bla\\n\");\n}\n\nThis will look good and align \"more bla bla\\n\" as\nintended no matter your tab setting.\nBut replacing the 8 spaces with a tab will\ncause it to look bad.\n\nAnd using tabs let me use the tabsetting I like (8) and other\nuse the tab setting they like (2,3,4,5,6,7) and all is good.\n\nAnd why a tab is 8 spaces and in considered good.\nThats to teach people to write small independent functions\nthat does _one_ thing and does it well.\nMega functions with 6 times indent or more usually needs to\nbe breaked up anyway.\n\n\tSam\n"},{"id":"56107","messageId":"20071016183401.GR16774@lug-owl.de","threadId":"10307","inReplyTo":"4714F3A2.3080103@op5.se","subject":"Re: On Tabs and Spaces","fromName":"Jan-Benedict Glaw","fromEmail":"jbglaw@lug-owl.de","sentAt":"2007-10-16T18:34:01Z","receivedAt":"2007-10-16T18:34:01Z","isPatch":false,"sender":{"key":"jbglaw@lug-owl.de","avatar":null},"body":"On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson wrote:\n> Jeffrey C. Ollie wrote:\n> > On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:\n> > > And if one change the tab size, it will result in a messy alignment in\n> > > line 5.\n> >\n> > Which is why one should never should change the tab size from anything\n> > but 8.\n> \n> I have mine set to 4. With an 11.2\" screen and 1024x768 resolution, it's\n\nYou fir 768 lines of text and 1024 chars per line to such a small\ndisplay and still argue about too large tabs?\n\nSCNR, JBG\n\n-- \n Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481\nSignature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck.\nthe second : Langsam möchte ich mal wieder weiterträumen können.\n -- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de)\n"},{"id":"56106","messageId":"47150839.4060207@op5.se","threadId":"10307","inReplyTo":"20071016183401.GR16774@lug-owl.de","subject":"Re: On Tabs and Spaces","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-16T18:51:37Z","receivedAt":"2007-10-16T18:51:37Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jan-Benedict Glaw wrote:\n> On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson wrote:\n>> Jeffrey C. Ollie wrote:\n>>> On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:\n>>>> And if one change the tab size, it will result in a messy alignment in\n>>>> line 5.\n>>> Which is why one should never should change the tab size from anything\n>>> but 8.\n>> I have mine set to 4. With an 11.2\" screen and 1024x768 resolution, it's\n> \n> You fir 768 lines of text and 1024 chars per line to such a small\n> display and still argue about too large tabs?\n> \n\nIf by \"char\" you mean \"pixel\", then yes.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56109","messageId":"alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org","threadId":"10307","inReplyTo":"3awb7zw6.fsf@blue.sea.net","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T19:20:50Z","receivedAt":"2007-10-16T19:20:50Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 Oct 2007, Jari Aalto wrote:\n\n> * Tue 2007-10-16 Michael Witten \n> >\n> > However, 8 spaces per tab is a lot of wasted\n> > information to be bandying about.\n> \n> Spaces are guaranteed to interpreted correctly in all environments. TABs\n> are the source of too many problems.\n\nNo.\n\nTabs are 8 spaces wide. Live with it. It's the only sane solution.\n\nThe fact is, people do mix the two. No ifs, buts or maybes about it. Even \nin the absense of any actual *spaces*, the size of a tab matters, since \nyou can - and do - have two separately indented things (the initial \nindentation, and then things like comments being indented separately).\n\nThe only sane solution is the one the kernel and git have always used: \ntabs are 8 spaces wide, and anybody who disagrees can go screw themselves. \nIf you don't have 8-character tabs, you *will* get odd indentation.\n\nAnd no, the answer is not to say \"don't use tabs at all\" and replace them \nby spaces. The answer is *also* not \"tabs are just for initial code \nindents\", because not only will most sane editors never even show the \ndifference, it's simply not how people work. So such a rule about \ninvisible things doesn't work.\n\nPeople who want to be contrary, and have a 2-character-wide tab only have \nthemselves to blame. It's THEIR problem, not somethign that is even worth \ntrying to address. \n\nIf there are problems with people having small screens, that is damn well \nnot about TAB, it's about code being way too deeply indented, and smaller \nindents are absolutely *not* the answer - they are part of the damn \nproblem to begin with.\n\nThe fact that some projects have encouraged bad coding style and *insane* \ntab values is not a git problem. We should teach people to do *better*, \nnot become worse just because others have done idiotic things.\n\n\t\t\t\tLinus\n"},{"id":"56111","messageId":"20071016193605.GA829@glandium.org","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-10-16T19:36:05Z","receivedAt":"2007-10-16T19:36:05Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:\n> \n> \n> On Tue, 16 Oct 2007, Jari Aalto wrote:\n> \n> > * Tue 2007-10-16 Michael Witten \n> > >\n> > > However, 8 spaces per tab is a lot of wasted\n> > > information to be bandying about.\n> > \n> > Spaces are guaranteed to interpreted correctly in all environments. TABs\n> > are the source of too many problems.\n> \n> No.\n> \n> Tabs are 8 spaces wide. Live with it. It's the only sane solution.\n\nActually, part of the mess with tabs is due to the fact they're not\nexactly 8 spaces wide, but any width that ends at a multiple of 8\ncharacters from the start of the line. So 0 <= n < 8 spaces and a tab\nis still 8 spaces.\n\nAnyways, it's maybe just simpler to run indent before sending patches.\n\nMike\n"},{"id":"56112","messageId":"alpine.LFD.0.999.0710161240510.6887@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071016193605.GA829@glandium.org","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T19:47:17Z","receivedAt":"2007-10-16T19:47:17Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 Oct 2007, Mike Hommey wrote:\n> \n> Actually, part of the mess with tabs is due to the fact they're not\n> exactly 8 spaces wide, but any width that ends at a multiple of 8\n> characters from the start of the line. So 0 <= n < 8 spaces and a tab\n> is still 8 spaces.\n\nUmm.. That's the definition of \"tab width\".\n\nThe tab width is 8. Not \"0 < n <= 8\". Not \"depends on where you are\". The \ntab width is 8.\n\nThe whole history of tab is that it comes from mechanical \"tab stops\" that \nyou could set, and that were independent of the text - pressing the tab \nkey would move to the next tab stop.\n\nNow, those tab stops were movable, and in fact, I think lots of terminals \nstill support setting those tab stops dynamically (ie you can send control \nsequences to set their \"tab stops\" to different points, exactly like an \nold mechanical typewriter).\n\nBut when it comes to computers, 8-character wide tab stops is the \nde-facto standard. It's what every single terminal defaults to. It's the \nonly thing that some printers/terminals support. Anything else is by \ndefinition non-standard.\n\n\t\t\tLinus\n"},{"id":"56113","messageId":"alpine.LFD.0.999.0710161247511.6887@woody.linux-foundation.org","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161240510.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T19:51:59Z","receivedAt":"2007-10-16T19:51:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 Oct 2007, Linus Torvalds wrote:\n> \n> But when it comes to computers, 8-character wide tab stops is the \n> de-facto standard. It's what every single terminal defaults to. It's the \n> only thing that some printers/terminals support. Anything else is by \n> definition non-standard.\n\nSide note: one reason you *have* to use 8-character wide tab stops if you \nwant to be sane is that while your editor may have alternate tab-stops, \nbut when you look at the sources any other ways or on any other setup, the \ndefault is *always* going to be that 8-character wide tab-stop.\n\nDo a \"git cat-file -p :Makefile\", and it will default to using \"less\". \nHave you added \"-x2\" to you LESS environment variable? Has everybody else? \nNot likely.\n\nOr what happens when you just cat it straight, without any less at all? \n\nIn short: using anything but 8-char wide tab-stops is INSANE, because it \nwill inevitably showing the same source code in different ways depending \non which editor or other environment you use.\n\nIn contrast, if you just accept that 8-wide tabs are a fact, you never see \nany of these issues. Everything \"just works\".\n\n\t\t\tLinus\n"},{"id":"56116","messageId":"1192565900.6430.16.camel@athena","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Tom Tobin","fromEmail":"korpios@korpios.com","sentAt":"2007-10-16T20:18:20Z","receivedAt":"2007-10-16T20:18:20Z","isPatch":false,"sender":{"key":"korpios@korpios.com","avatar":null},"body":"On Tue, 2007-10-16 at 12:20 -0700, Linus Torvalds wrote:\n> The only sane solution is the one the kernel and git have always used: \n> tabs are 8 spaces wide, and anybody who disagrees can go screw themselves. \n> If you don't have 8-character tabs, you *will* get odd indentation.\n> \n> And no, the answer is not to say \"don't use tabs at all\" and replace them \n> by spaces. The answer is *also* not \"tabs are just for initial code \n> indents\", because not only will most sane editors never even show the \n> difference, it's simply not how people work. So such a rule about \n> invisible things doesn't work.\n[...]\n> The fact that some projects have encouraged bad coding style and *insane* \n> tab values is not a git problem. We should teach people to do *better*, \n> not become worse just because others have done idiotic things.\n\nI'm reading two different ideas here, and it seems like you're\nconflating the two — and, in the process, telling some pretty smart\npeople (smarter than me, anyhow) to go fuck themselves.\n\nIf a project uses tabs, your statement regarding 8-char-width tabs makes\nsense; you need some rule by which you can assume others are viewing the\nsame thing you are.\n\nBut you then dismiss out of hand the option of using all spaces; Python\nhas been getting along perfectly well for quite some time by following\nthis rule, and my experience with the language leads me to believe it's\nthe wiser of the choices. Questions over tab width simply *go away*;\nyou pick an indentation level (Python uses 4) and stick with it.\n\nI'm not arguing that git should switch to all spaces; projects tend to\nbecome set in their ways, and consistency can be valuable. I'm merely\npointing out that all-spaces is a quite *sane* option, even if it's one\ngit doesn't choose.\n"},{"id":"56120","messageId":"vpqbqayreat.fsf@bauges.imag.fr","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161240510.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-10-16T20:32:26Z","receivedAt":"2007-10-16T20:32:26Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 16 Oct 2007, Mike Hommey wrote:\n>> \n>> Actually, part of the mess with tabs is due to the fact they're not\n>> exactly 8 spaces wide, but any width that ends at a multiple of 8\n>> characters from the start of the line. So 0 <= n < 8 spaces and a tab\n>> is still 8 spaces.\n>\n> Umm.. That's the definition of \"tab width\".\n>\n> The tab width is 8. Not \"0 < n <= 8\". Not \"depends on where you are\". The \n> tab width is 8.\n\nRead better before replying, and I'm sure you'll agree with Mike ...\n\n-- \nMatthieu\n"},{"id":"56123","messageId":"20071016205626.GA1835@uranus.ravnborg.org","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2007-10-16T20:56:26Z","receivedAt":"2007-10-16T20:56:26Z","isPatch":false,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:\n> \n> The answer is *also* not \"tabs are just for initial code \n> indents\", because not only will most sane editors never even show the \n> difference, it's simply not how people work. So such a rule about \n> invisible things doesn't work.\nIt is insane to *require* diciplined people to use tabs for more than\ncode indents.\nIf you insist on using tabs all over the place - fine with me.\nBut do not frown upon me and other diciplined people becasue we use\nspaces to make sure our arguments to a function call is properly\naligned in a tab=10,tab=8,tab=2 environment.\n\nThe arguments \"tabs are always 8 spaces properly aligned\" is just\nto reach the lowest common denominator around developers.\nAnd frankly there are some that do better than that.\n\nThe root casue are the stupid editors that does not make it\neasy to be diciplined and thats where the errors come from\nand all the stupid rules like the above.\n\n\tSam\n"},{"id":"56143","messageId":"alpine.LFD.0.999.0710161559150.6887@woody.linux-foundation.org","threadId":"10307","inReplyTo":"1192565900.6430.16.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-16T23:05:34Z","receivedAt":"2007-10-16T23:05:34Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 Oct 2007, Tom Tobin wrote:\n> \n> But you then dismiss out of hand the option of using all spaces\n\nI do indeed. I don't think it's sensible. And I did think I already \nanswered that issue by talking about how most editors don't even support \nit or show the difference between tabs and spaces.\n\nFor example, the editor I use - microemacs - supports tabs just fine. It \ndoes auto-indentation etc. But it does it with hard-tabs by default, so \nnow you have to have some editor-specific setup for that particular \nproject if you ever want to do anything else.\n\nAnd that's really what it boils down to. Everybody support 8-character \nhardtabs (and usually by default). They may support other things *too*, \nbut any time you move away from that standard behaviour, you'll most \nlikely find something that doesn't support the alternatives.\n\nSo yes, the answer really is: \"git uses 8-character hard-tabs, live with \nit\". \n\n\t\tLinus\n"},{"id":"56144","messageId":"20071016230952.GA18099@machine.or.cz","threadId":"10307","inReplyTo":"20071016174026.GA506@uranus.ravnborg.org","subject":"Re: On Tabs and Spaces","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-10-16T23:09:53Z","receivedAt":"2007-10-16T23:09:53Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Oct 16, 2007 at 07:40:26PM +0200, Sam Ravnborg wrote:\n> Tabs should be used for indent and not general alignment.\n> \n> Consider:\n> if (some long condition that\n> ....&& spans two lines) {\n> my_private_printf(\"bla bla bla\"\n> ..................\"more bla bla\\n\");\n> }\n> \n> This will look good and align \"more bla bla\\n\" as\n> intended no matter your tab setting.\n> But replacing the 8 spaces with a tab will\n> cause it to look bad.\n\nI'd so much love to have this and sometimes do this even manually, but\ndoes anyone have an idea how to make vim do this for me? I never got\naround to investigate this in depth or possibly make a patch...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nEarly to rise and early to bed makes a male healthy and wealthy and dead.\n -- James Thurber\n"},{"id":"56153","messageId":"20071017015109.303760cc@localhost.localdomain","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161559150.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Christer Weinigel","fromEmail":"christer@weinigel.se","sentAt":"2007-10-16T23:51:09Z","receivedAt":"2007-10-16T23:51:09Z","isPatch":false,"sender":{"key":"christer@weinigel.se","avatar":null},"body":"On Tue, 16 Oct 2007 16:05:34 -0700 (PDT)\nLinus Torvalds wrote:\n\n> I do indeed. I don't think it's sensible. And I did think I already \n> answered that issue by talking about how most editors don't even\n> support it or show the difference between tabs and spaces.\n> \n> For example, the editor I use - microemacs - supports tabs just fine.\n> It does auto-indentation etc. But it does it with hard-tabs by\n> default, so now you have to have some editor-specific setup for that\n> particular project if you ever want to do anything else.\n> \n> And that's really what it boils down to. Everybody support\n> 8-character hardtabs (and usually by default). They may support other\n> things *too*, but any time you move away from that standard\n> behaviour, you'll most likely find something that doesn't support the\n> alternatives.\n\nUnfortunately most editors are totally confused about the difference\nbetween tab size and indentation level. Visual Studio, probably the\nmost commonly used development environment on Windows, by default uses\nTAB characters that are 4 spaces wide, and users are recommended\nnot to change that because of that a lot of existing Windows source code\nand examples uses those settings.\n\nTwo years ago, when I last looked at it, Eclipse, a very commonly used\ndevelopment environment, managed to confuse tabs and indentation and\nmake it almost impossible to write Java or C code with a tab size of 8\nwith a different indentation level. The Eclipse 3 betas did see some\nimprovement there, I think it got possible to do the right thing in\nJava at least, but the normal text editor and C editor lagged behind.\nBut it was still a big mess and it was much too easy for someone to get\na tab size which is not 8. Hopefully this has been fixed by now, but I\nwouldn't bet any significant amount of money on it.\n\nNedit (which runs on Linux) has a very confusing settings dialog with\nterms such as \"tab spacing\", \"emulated tabs\". I guess emulated tabs\nmeans the indentation level, but guess how easy that is to mess up.\n\ngedit can control the tab width, but has no setting at all for\nconfiguring the indentation level. Guess what people do when they want\na 4 space indentation level? Yes, right, change the tab size to 4.\n\nA a former colleague who used visual slickedit usually produced code\nwith tab size 4. I think I've gotten the same crap from ultra edit 32\nusers.\n\nAnd so on... Mercifully, _all_ of these editors have a setting to use\nspaces instead of tabs, and telling people to turn on that setting is\nthe absolutely easiest way of making things \"just work\". Yes, I know,\nthe correct answer is to tell people to always use tab size 8, and I\nfrequently and loudly do that. But at the same time, perfect is the\nenemy of good. It's much easier to explain \"tabs will act differently\nin different editors, but if you always us spaces it will not be a\nproblem\" than to get into a discussion about the semantic difference\nbetween tab size and indentation.\n\nIf you assume that everyone is sane and use a tab size of 8 you will\nget bitten, sooner or later. Or actually, you, Linus, who are lucky\nenough to work mostly with Linux source, you might personally not get\nbitten all that often. But us poor suckers that have to work with\nother people, often Windows programmers, we do.\n\n /Christer\n"},{"id":"56162","messageId":"alpine.LFD.0.999.0710161722320.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071017015109.303760cc@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T00:45:51Z","receivedAt":"2007-10-17T00:45:51Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Christer Weinigel wrote:\n> \n> If you assume that everyone is sane and use a tab size of 8 you will\n> get bitten, sooner or later. Or actually, you, Linus, who are lucky\n> enough to work mostly with Linux source, you might personally not get\n> bitten all that often. But us poor suckers that have to work with\n> other people, often Windows programmers, we do.\n\nOne issue may well be that Windows programmers also probably don't work \nvery much with patches, do they?\n\nOne reason for *really* wanting to use hard-tabs is that it makes patches \nlook better, exactly because diffs contain that one extra (or two, in the \ncase of old-style context diffs) character at the beginning of the line.\n\nWhich means that while all-space indents look fine, *mixing* styles \ndefinitely does not. In particular, a two-character indent (which \nhopefully nobody uses, but people are crazy) will be totally unreadable as \na patch if you have the (fairly common, at least in UNIX projects) style \nof using spaces for less-than-eight-character-indents and tabs for the \nfull 8 characters.\n\n(In particular, a 3-level and 4-level indent will look *identical* in such \na project, when using context diffs).\n\nAnd sure, you can use all-spaces-everywhere, but that just isn't what any \nnormal UNIX editors are set up for by default. In contrast, under UNIX, I \ncan pretty much guarantee that hard-tab indents look at least reasonable \nin any editor.\n\nAnd if you have an editor that shows hard-tabs as 4-character indents, \ngenerally you can work with it. You may have odd indentation, and people \nmay complain about your patches not lining up, and yes, it would be up to \n*you* to understand that 8-wide tabs are the normal and default. But you \ncan certainly work with a source base that uses a single hard-tab for \nindentation.\n\nIn contrast, if you use spaces (or worse - mixing), things really look \nugly as sin, to the point of actually being unworkable.\n\nIn short:\n\n - if the project has the rule that an indentation is \"one hard-tab\", then \n at least everybody can *work* with that project. Different people may \n see things laid out slightly differently, but it's generally not a \n horrible disaster, especially if you aim to use block comments indented \n with the code (like we *mostly* do both in the kernel and in git)\n\n - all-space and all-tabs just leads to problems. Yes, I know about \n python, but lets face it, python is different, since the spacing has \n semantic rules there. Most non-python programmers will not use editors \n where you can obviously see the difference between spaces and tabs, and \n as a result an all-space model will *turn* into a mixed-space/tab \n model, and you get horrible end results.\n\n - as per above, mixing spaces and tabs is a *horrid* idea. \n\n - as a result, a \"pure tab for indents\" model tends to be workable in \n most situations. It may not be ideal for you, but it's workable.\n\n - and at least in the UNIX world, default for pure tabs really is 8 \n characters. Even if you have an editor that shows them as four, you'll \n see different results outside the editor (eg \"grep -5 file.c\"), so \n people should just consider other tab sizes to be \"secondary\".\n\n And as long as 99% of all git developers are under Linux, and all the \n core ones seem to have had no problem with the current tab rules, I \n really don't see why that should change.\n\nSee? Hard-tabs are good. Maybe Windows people don't ever see patches \n(perhaps they only see them as side-by-side graphical things), and maybe \nwindows projects are always done inside *one* environment where there is \nno \"grep\" and \"terminal TAB size\" and \"fifty different editors with \ndifferent defaults\".\n\nBut even in DOS/Windows, hard-tabs seem to be quite common, judging by \nwhat little source code I've seen from Windows projects. \n\nAnd I just checked. The current git model seems to work fine if you have \nan editor that thinks tabs are 4 spaces:\n\n\tsed 's/\t/ /g' < revision.c | less -S\n\n(that's a hard-tab in that first regex). No, things don't necessarily line \nup just like they should, but you actually have to *look* for problems to \nsee them (ie stuff where people have added line-breaks).\n\nAnd is it really so unreasonable to just say \"8-character tabs are the \ngold standard\"?\n\n\t\t\tLinus\n"},{"id":"56191","messageId":"B01BBB60-6231-4AF6-9A64-10374464E442@mit.edu","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161722320.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-17T03:08:09Z","receivedAt":"2007-10-17T03:08:09Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 16 Oct 2007, at 8:45:51 PM, Linus Torvalds wrote:\n\n> And is it really so unreasonable to just say \"8-character tabs are the\n> gold standard\"?\n\nIt's unreasonable not to list that anywhere.\n\nmfwitten\n"},{"id":"56193","messageId":"alpine.LFD.0.999.0710162019150.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"B01BBB60-6231-4AF6-9A64-10374464E442@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T03:29:01Z","receivedAt":"2007-10-17T03:29:01Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 16 Oct 2007, Michael Witten wrote:\n> \n> On 16 Oct 2007, at 8:45:51 PM, Linus Torvalds wrote:\n> \n> > And is it really so unreasonable to just say \"8-character tabs are the\n> > gold standard\"?\n> \n> It's unreasonable not to list that anywhere.\n\nHeh.\n\nI was sure we had a \"CodingStyle\", but it turns out that no, we don't, and \nyes, the 8-tab assumption is implicit in (a) the kernel rules (which git \nstarted out following for obvious reasons, and which *does* have \ndocumentation making this very explicit indeed) and (b) those few places \nwhere you can actually see it in the result.\n\nSo maybe it should be made explicit. You can see the effect right now by \ndoing\n\n\tgit grep -1 '\t ' *.c\n\n(again, that regex is a \"tab+space\", although it's not obvious) and then \nlooking for places where we line up things in ways that simply wouldn't \nhave worked if it wasn't a 8-wide tab, ie things like\n\n\t...\n\tcheck_all_attr = xrealloc(check_all_attr,\n\t\t\t\t sizeof(*check_all_attr) * attr_nr);\n\t..\n\tread_tree_recursive(args->tree, args->base, plen, 0,\n\t\t\t args->pathspec, write_zip_entry);\n\t..\n\nwhere the arguments wouldn't line up for anything but 8-char-wide tabs.\n\n(But the code is certainly *readable* with other tab sizes, so it's not \nlike this makes it impossible to work if somebody has a 4-space tab, it \njust means that such people can get odd effects - but they may not even \nrealize that others see things line up!)\n\n\t\tLinus\n"},{"id":"56194","messageId":"402731c90710162041q457c7dd3tf906ba0c6faf29ca@mail.gmail.com","threadId":"10307","inReplyTo":"20071016230952.GA18099@machine.or.cz","subject":"Re: On Tabs and Spaces","fromName":"David","fromEmail":"davvid@gmail.com","sentAt":"2007-10-17T03:41:34Z","receivedAt":"2007-10-17T03:41:34Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On 10/16/07, Petr Baudis wrote:\n> On Tue, Oct 16, 2007 at 07:40:26PM +0200, Sam Ravnborg wrote:\n> > Tabs should be used for indent and not general alignment.\n> >\n> > Consider:\n> > if (some long condition that\n> > ....&& spans two lines) {\n> > my_private_printf(\"bla bla bla\"\n> > ..................\"more bla bla\\n\");\n> > }\n> >\n> > This will look good and align \"more bla bla\\n\" as\n> > intended no matter your tab setting.\n> > But replacing the 8 spaces with a tab will\n> > cause it to look bad.\n>\n> I'd so much love to have this and sometimes do this even manually, but\n> does anyone have an idea how to make vim do this for me? I never got\n> around to investigate this in depth or possibly make a patch...\n>\n> --\n> Petr \"Pasky\" Baudis\n> Early to rise and early to bed makes a male healthy and wealthy and dead.\n> -- James Thurber\n\n\nHello\nI use both vim and emacs so I must be weird.\nAnyways, here's some useful vim settings that I've come across:\n\nset tabstop=8\nset softtabstop=8\nset shiftwidth=8\nset noexpandtab\nset list\nset listchars=:.\\\n\nThe last two are extremely useful, especially if you're hacking on\npython. That's\nlistchars=(less-than)tab(greater-than)(colon)(dot)(backslash)(space)\n(don't forget the space!).\n\nThat makes vim display tabs with a \".\" indicator, so you have a very\nclear view of when tabs are in use. This has helped me countless\ntimes.\n\nYou can use any character in there instead of dot. I actually use an\nextended ascii character since it looks nicer but I didn't want to\nrisk email mangling it.\n\n-- \n David\n"},{"id":"56203","messageId":"85lka2ffmk.fsf@lola.goethe.zz","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161559150.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-17T05:56:50Z","receivedAt":"2007-10-17T05:56:50Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 16 Oct 2007, Tom Tobin wrote:\n>> \n>> But you then dismiss out of hand the option of using all spaces\n>\n> I do indeed. I don't think it's sensible.\n\nActually, it seriously degrades (both performance and savings)\ndeltifying once you reach an indentation of 16.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"56212","messageId":"3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161722320.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2007-10-17T07:17:08Z","receivedAt":"2007-10-17T07:17:08Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"I'm late in this game. But it's too classic a debate to miss the fun.\n\nOn Oct 16, 2007, at 5:45 PM, Linus Torvalds wrote:\n> One issue may well be that Windows programmers also probably don't \n> work\n> very much with patches, do they?\n>\n> One reason for *really* wanting to use hard-tabs is that it makes \n> patches\n> look better, exactly because diffs contain that one extra (or two, \n> in the\n> case of old-style context diffs) character at the beginning of the \n> line.\n>\n> Which means that while all-space indents look fine, *mixing* styles\n> definitely does not. In particular, a two-character indent (which\n> hopefully nobody uses, but people are crazy) will be totally \n> unreadable as\n> a patch if you have the (fairly common, at least in UNIX projects) \n> style\n> of using spaces for less-than-eight-character-indents and tabs for the\n> full 8 characters.\n\nYes, all-space would look fine in patches. It'll look better than all \ntabs for tables and ascii formula and diagrams in comments, as one \nprepended character could screw up the tabs (depending on the \ncontent), rendering them totally unreadable. In all-space case, \nthings just shift to the right by one character column.\n\nI believe the indentation convention for ruby is 2 spaces. It looks \ntight to me :)\n\n> (In particular, a 3-level and 4-level indent will look *identical* \n> in such\n> a project, when using context diffs).\n>\n> And sure, you can use all-spaces-everywhere, but that just isn't \n> what any\n> normal UNIX editors are set up for by default. In contrast, under \n> UNIX, I\n> can pretty much guarantee that hard-tab indents look at least \n> reasonable\n> in any editor.\n\nBut all-space would look perfect in any editor as the authors \nintended, including the tables and ascii arts, as long as it's using \nmonospace font. It's easy to setup all space editing on all platforms \n(Windows, Mac, *nix) It's also much easier to enforce. I've used pre- \ncommit hook to check for tabs in the source and reject them if a tab \nis found :)\n\n> And if you have an editor that shows hard-tabs as 4-character indents,\n> generally you can work with it. You may have odd indentation, and \n> people\n> may complain about your patches not lining up, and yes, it would be \n> up to\n> *you* to understand that 8-wide tabs are the normal and default. \n> But you\n> can certainly work with a source base that uses a single hard-tab for\n> indentation.\n\n> In contrast, if you use spaces (or worse - mixing), things really look\n> ugly as sin, to the point of actually being unworkable.\n>\n\nWell, we just established that all-space is perfect, look-wise.\n\n> In short:\n>\n> - if the project has the rule that an indentation is \"one hard- \n> tab\", then\n> at least everybody can *work* with that project. Different \n> people may\n> see things laid out slightly differently, but it's generally not a\n> horrible disaster, especially if you aim to use block comments \n> indented\n> with the code (like we *mostly* do both in the kernel and in git)\n>\n> - all-space and all-tabs just leads to problems. Yes, I know about\n> python, but lets face it, python is different, since the spacing \n> has\n> semantic rules there. Most non-python programmers will not use \n> editors\n> where you can obviously see the difference between spaces and \n> tabs, and\n> as a result an all-space model will *turn* into a mixed-space/tab\n> model, and you get horrible end results.\n\nAs I mentioned, an all-space policy is trivial to enforce.\n\n> - as per above, mixing spaces and tabs is a *horrid* idea.\n>\n> - as a result, a \"pure tab for indents\" model tends to be workable in\n> most situations. It may not be ideal for you, but it's workable.\n>\n> - and at least in the UNIX world, default for pure tabs really is 8\n> characters. Even if you have an editor that shows them as four, \n> you'll\n> see different results outside the editor (eg \"grep -5 file.c\"), so\n> people should just consider other tab sizes to be \"secondary\".\n>\n> And as long as 99% of all git developers are under Linux, and \n> all the\n> core ones seem to have had no problem with the current tab rules, I\n> really don't see why that should change.\n>\n> See? Hard-tabs are good. Maybe Windows people don't ever see patches\n> (perhaps they only see them as side-by-side graphical things), and \n> maybe\n> windows projects are always done inside *one* environment where \n> there is\n> no \"grep\" and \"terminal TAB size\" and \"fifty different editors with\n> different defaults\".\n>\n> But even in DOS/Windows, hard-tabs seem to be quite common, judging by\n> what little source code I've seen from Windows projects.\n>\n> And I just checked. The current git model seems to work fine if you \n> have\n> an editor that thinks tabs are 4 spaces:\n>\n> \tsed 's/\t/ /g' < revision.c | less -S\n>\n> (that's a hard-tab in that first regex). No, things don't \n> necessarily line\n> up just like they should, but you actually have to *look* for \n> problems to\n> see them (ie stuff where people have added line-breaks).\n>\n> And is it really so unreasonable to just say \"8-character tabs are the\n> gold standard\"?\n\nBut I still haven't seen any compelling arguments against the \"all \nspace\" case, other than \"people will screw it up into mixed spaces\", \nwhich is really a straw man, as many multi-platform projects enforced \nthe all-space policy easily by using a pre-commit hook in \nmaintainers' repository.\n\nThe only downside of all-space is a moderate space bloat in source, \nwhich is insignificant, all things considered.\n\nI agree that \"8-character tabs are the gold standard\", only for the \ntabstop==8 part but not the indent==tab part. For me the question is: \nis it really so unreasonable to just say \"all-space is the holy grail\"?\n\n__Luke\n"},{"id":"56223","messageId":"E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu","threadId":"10307","inReplyTo":"3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com","subject":"Re: On Tabs and Spaces","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-17T09:09:19Z","receivedAt":"2007-10-17T09:09:19Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"\nOn 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n\n> But I still haven't seen any compelling arguments against the \"all \n> space\" case\n\nOverhead!\n\nIf you use 8 spaces instead of one tab,\nthat's using up 7x more space!\n\nConsider:\n\n # calculates the extra space required to\n # use the given number of spaces/tab.\n size()\n {\n count=`grep -RIo \"\\`printf \\\"\\t\\\"\\`\" . | wc -l`;\n perl -e \"print $count*$(($1-1))/1024/1024 . \\\" MB\\n\\\"\";\n }\n\n Then in in a git working tree:\n\n size 8; # 1.28701210021973 MB\n size 4; # 0.551576614379883 MB\n\n In a linux kernel working tree:\n\n size 8; # 61.4902725219727 MB\n size 4; # 26.3529739379883 MB\n\nConclusion:\n\n Yikes!\n\n\nI hate tabs, but I can't argue with that!\n\nMichael Witten\n"},{"id":"56230","messageId":"A73C6BE2-F990-4634-B996-02CB9B129155@vicaya.com","threadId":"10307","inReplyTo":"E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Luke Lu","fromEmail":"git@vicaya.com","sentAt":"2007-10-17T10:03:46Z","receivedAt":"2007-10-17T10:03:46Z","isPatch":false,"sender":{"key":"git@vicaya.com","avatar":null},"body":"\nOn Oct 17, 2007, at 2:09 AM, Michael Witten wrote:\n>\n> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n>\n>> But I still haven't seen any compelling arguments against the \"all \n>> space\" case\n>\n> Overhead!\n>\n> If you use 8 spaces instead of one tab,\n> that's using up 7x more space!\n>\n> Consider:\n>\n> # calculates the extra space required to\n> # use the given number of spaces/tab.\n> size()\n> {\n> count=`grep -RIo \"\\`printf \\\"\\t\\\"\\`\" . | wc -l`;\n> perl -e \"print $count*$(($1-1))/1024/1024 . \\\" MB\\n\\\"\";\n> }\n>\n> Then in in a git working tree:\n>\n> size 8; # 1.28701210021973 MB\n> size 4; # 0.551576614379883 MB\n\nFirst, the overhead is not a simple x4 or x8 conversion in size, but \nit's the upper bound. Given that, let's look at the percentage of the \noverhead: my git working tree is 56MB after gc, so the overhead is \n2.3% max for size 8 and 0.98% for size 4. That's not significant at all.\n\n>\n> In a linux kernel working tree:\n>\n> size 8; # 61.4902725219727 MB\n> size 4; # 26.3529739379883 MB\n>\n> Conclusion:\n>\n> Yikes!\n\nNow, compile the kernel, do a du in the tree and report back \npercentages of the overhead.\n\nDisk is cheap (1GB costs less than half a dollar), people's \nproductivity/time is not. The overhead argument is compelling, not!\n\n__Luke\n \n"},{"id":"56231","messageId":"dbfc82860710170321l458ebd1cr6bf619cef9bb7300@mail.gmail.com","threadId":"10307","inReplyTo":"E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-10-17T10:21:30Z","receivedAt":"2007-10-17T10:21:30Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 10/17/07, Michael Witten wrote:\n>\n> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n>\n> > But I still haven't seen any compelling arguments against the \"all\n> > space\" case\n>\n> Overhead!\n>\n> If you use 8 spaces instead of one tab,\n> that's using up 7x more space!\n>\n> Consider:\n>\n> # calculates the extra space required to\n> # use the given number of spaces/tab.\n> size()\n> {\n> count=`grep -RIo \"\\`printf \\\"\\t\\\"\\`\" . | wc -l`;\n> perl -e \"print $count*$(($1-1))/1024/1024 . \\\" MB\\n\\\"\";\n> }\n>\n> Then in in a git working tree:\n>\n> size 8; # 1.28701210021973 MB\n> size 4; # 0.551576614379883 MB\n>\n> In a linux kernel working tree:\n>\n> size 8; # 61.4902725219727 MB\n> size 4; # 26.3529739379883 MB\n\nAs already pointed out, this isn't the true waste. Run the following\nRuby script to determine the true waste:\n\n------------ cut here -----------\nTabWidth = 8\n\nactual_size = 0\nexpanded_size = 0\nARGF.each_line do |line|\n width = 0\n line.each_byte do |byte|\n width += (byte == ?\\t) ? (TabWidth - (width % TabWidth)) : 1\n end\n actual_size += line.length\n expanded_size += width\nend\nputs (expanded_size - actual_size).to_s\n------------ cut here -----------\n\nThis will give you the actual space waste. Run it like so:\n\n% ruby space-waste.rb /usr/src/linux/**/*.[ch]\n\n(or in a similar manner that doesn't fail due to going over the\nmaximum command-line limit).\n\nAccording to this calculation the waste is 47808782 bytes, or about\n45.6 MiB, for 8-spaces-wide tabs.\n"},{"id":"56238","messageId":"6A484AE6-ECCD-4473-BEF8-3451EBF8FAFF@mit.edu","threadId":"10307","inReplyTo":"dbfc82860710170321l458ebd1cr6bf619cef9bb7300@mail.gmail.com","subject":"Re: On Tabs and Spaces","fromName":"Michael Witten","fromEmail":"mfwitten@mit.edu","sentAt":"2007-10-17T11:23:31Z","receivedAt":"2007-10-17T11:23:31Z","isPatch":false,"sender":{"key":"mfwitten@gmail.com","avatar":"https://avatars.githubusercontent.com/u/597101?v=4"},"body":"On 17 Oct 2007, at 6:21:30 AM, Nikolai Weibull wrote:\n\n> According to this calculation the waste is 47808782 bytes, or about\n> 45.6 MiB, for 8-spaces-wide tabs.\n\nI concede my calculation was crude.\n\nInterestingly, modifying my calculation to look\nfor tabs at the beginning of the line gives a\nsimilar result:\n\n # calculates the extra space required to\n # use the given number of spaces/tab.\n size()\n {\n count=`grep -RIo \"^\\`printf \\\"\\t\\\"\\`\" . | wc -l`;\n perl -e \"print $count*$(($1-1))/1024/1024 . \\\" MiB\\n\\\"\";\n }\n\n size 8; => 49.7416791915894 MiB\n\nand for git:\n\t\n size 8; => 1.25082969665527 MiB\n\n\nAnyway, thanks for the neat script.\n\nmfwitten\n"},{"id":"56239","messageId":"200710171232.13062.andyparkins@gmail.com","threadId":"10307","inReplyTo":"402731c90710162041q457c7dd3tf906ba0c6faf29ca@mail.gmail.com","subject":"Re: On Tabs and Spaces","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-17T11:32:13Z","receivedAt":"2007-10-17T11:32:13Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 October 17, David wrote:\n\n> The last two are extremely useful, especially if you're hacking on\n> python. That's\n> listchars=(less-than)tab(greater-than)(colon)(dot)(backslash)(space)\n> (don't forget the space!).\n\nOn the subject of high-ascii chars. Here's my favourite for your .vimrc\n\n execute 'set listchars+=tab:'.nr2char(187).nr2char(183)\n\n187 is the \"significantly greater than\" symbol and 183 is a central dot. i.e. \nevery character of a tab is non-space. The actual characters used aren't \nactually the point I wanted to make; the thing here is that two non-space \ncharacters are used, so every column occupied by the tab is visible - this \nmakes it very easy to see where tabs end and spaces begin.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"56255","messageId":"alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T15:53:55Z","receivedAt":"2007-10-17T15:53:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Luke Lu wrote:\n> \n> Well, we just established that all-space is perfect, look-wise.\n\nBut we also established that an all-space model is not stable, because any \nunix developers will start adding tabs instead of spaces.\n\n> As I mentioned, an all-space policy is trivial to enforce.\n\nHell no, it's not.\n\nMore importantly, I can guarantee that certain developers will refuse to \nbe part of such a project with such an idiotic design that eats disk-space \nfor no gain, and makes it impossible for me to use my normal editor.\n\n> But I still haven't seen any compelling arguments against the \"all space\"\n> case, other than \"people will screw it up into mixed spaces\", which is really\n> a straw man, as many multi-platform projects enforced the all-space policy\n> easily by using a pre-commit hook in maintainers' repository.\n\nHey, you start your own projct, and you can enforce whatever idiotic rules \nyou want to. \n\nBut in the meantime, all-tab indentations are equally good, and are the \ndefacto rule. So *you* are the one who should show compelling arguments \nfor changing, and so far you haven't shown any.\n\nReally: what is the problem with hardtabs? Absolutely none.\n\n\t\t\tLinus\n"},{"id":"56258","messageId":"86sl49g1w1.fsf@lola.quinscape.zz","threadId":"10307","inReplyTo":"3A9408D5-2667-43A6-A0CE-C0720B3A3987@vicaya.com","subject":"Re: On Tabs and Spaces","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-17T16:08:14Z","receivedAt":"2007-10-17T16:08:14Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Luke Lu writes:\n\n> But I still haven't seen any compelling arguments against the \"all\n> space\" case, other than \"people will screw it up into mixed spaces\",\n> which is really a straw man, as many multi-platform projects\n> enforced the all-space policy easily by using a pre-commit hook in\n> maintainers' repository.\n\nAll-space indentation renders the binary delta algorithm git uses for\ncompression of packs slow and partly inoperative (all sequences of 16\nspaces share the same finger print, and the number of identical finger\nprints for which the file information is kept is reduced to 64).\n\n> The only downside of all-space is a moderate space bloat in source,\n> which is insignificant, all things considered.\n\nIt will also slow down git's packing and make it produce worse\nresults.\n\n> I agree that \"8-character tabs are the gold standard\", only for the\n> tabstop==8 part but not the indent==tab part. For me the question\n> is: is it really so unreasonable to just say \"all-space is the holy\n> grail\"?\n\nYes.\n\n-- \nDavid Kastrup\n"},{"id":"56267","messageId":"alpine.LFD.0.9999.0710171337330.19446@xanadu.home","threadId":"10307","inReplyTo":"86sl49g1w1.fsf@lola.quinscape.zz","subject":"Re: On Tabs and Spaces","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-17T17:44:39Z","receivedAt":"2007-10-17T17:44:39Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 17 Oct 2007, David Kastrup wrote:\n\n> Luke Lu writes:\n> \n> > But I still haven't seen any compelling arguments against the \"all\n> > space\" case, other than \"people will screw it up into mixed spaces\",\n> > which is really a straw man, as many multi-platform projects\n> > enforced the all-space policy easily by using a pre-commit hook in\n> > maintainers' repository.\n> \n> All-space indentation renders the binary delta algorithm git uses for\n> compression of packs slow and partly inoperative (all sequences of 16\n> spaces share the same finger print, and the number of identical finger\n> prints for which the file information is kept is reduced to 64).\n\nBut sequences of 16 spaces are unlikely to land on 16-byte boundaries \nall the time in the file so adjacent data to those 16-space blocks will \nstill provide good hashing.\n\n> > The only downside of all-space is a moderate space bloat in source,\n> > which is insignificant, all things considered.\n> \n> It will also slow down git's packing and make it produce worse\n> results.\n\nIf that was effectively the case then it is Git that had to be fixed and \nnot the way people write code. Git should cope with the data it is fed \nand not the other way around.\n\nAnd this is completely orthogonal to the policy of using hard tabs or \nspaces in source code, so I'm clearly _not_ providing any argument to \nthat discussion one way or the other here.\n\n\nNicolas\n"},{"id":"56268","messageId":"BAYC1-PASMTP126D526163BEA68991F905AE9D0@CEZ.ICE","threadId":"10307","inReplyTo":"86sl49g1w1.fsf@lola.quinscape.zz","subject":"Re: On Tabs and Spaces","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2007-10-17T17:51:30Z","receivedAt":"2007-10-17T17:51:30Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, October 17, 2007 12:08 pm, David Kastrup said:\n\n>\n> All-space indentation renders the binary delta algorithm git uses for\n> compression of packs slow and partly inoperative (all sequences of 16\n> spaces share the same finger print, and the number of identical finger\n> prints for which the file information is kept is reduced to 64).\n\nYou seem to have identified a weakness in Git's design rather than\nan argument against using all-space indentation. Personally I find it\ncounter-productive and annoying to work in space-indented source code.\nBut let's be honest, this \"issue\" is mostly about familiarity and\ncomfort rather than some deep objective truth.\n\nSean\n"},{"id":"56271","messageId":"Pine.LNX.4.64.0710171903340.25221@racer.site","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-17T18:05:21Z","receivedAt":"2007-10-17T18:05:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Oct 2007, Linus Torvalds wrote:\n\n> On Wed, 17 Oct 2007, Luke Lu wrote:\n> \n> > As I mentioned, an all-space policy is trivial to enforce.\n> \n> Hell no, it's not.\n> \n> More importantly, I can guarantee that certain developers will refuse to \n> be part of such a project with such an idiotic design that eats \n> disk-space for no gain, and makes it impossible for me to use my normal \n> editor.\n\nYes. Me, for one.\n\nBut heck, _everyone_ is free to fork. That is one of the missions of git: \n\"fork!\". You can maintain you tab-less fork, until people flock to you, \ndeciding to use your repo instead of Junio's, or Shawn's. If enough \npeople decide, you will have more followers than the others.\n\nCiao,\nDscho\n"},{"id":"56274","messageId":"1192645509.6640.21.camel@athena","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Tom Tobin","fromEmail":"korpios@korpios.com","sentAt":"2007-10-17T18:25:09Z","receivedAt":"2007-10-17T18:25:09Z","isPatch":false,"sender":{"key":"korpios@korpios.com","avatar":null},"body":"On Wed, 2007-10-17 at 08:53 -0700, Linus Torvalds wrote:\n> \n> On Wed, 17 Oct 2007, Luke Lu wrote:\n> > \n> > Well, we just established that all-space is perfect, look-wise.\n> \n> But we also established that an all-space model is not stable, because any \n> unix developers will start adding tabs instead of spaces.\n\nDamn unix developers! They just can't be controlled!\n\n... seriously now. You're trying on one hand to enforce a particular\nindentation rule (use tabs for indentations, assume tabs are 8\ncharacters wide, use spaces for partial indentation) — which assumes\nunix developers *can* follow a project's rules for coding style — and\nyet you're arguing *against* all-spaces because unix developers *can't*\nfollow rules.\n\nOr is \"unix developers\" code for \"my sample size of one\"?\n\n> > As I mentioned, an all-space policy is trivial to enforce.\n> \n> Hell no, it's not.\n> \n> More importantly, I can guarantee that certain developers will refuse to \n> be part of such a project with such an idiotic design that eats disk-space \n> for no gain, and makes it impossible for me to use my normal editor.\n\nInteresting how you waver between \"certain developers\" and \"me\". I'm\nconvinced at this point that your argument comes down to \"I can't use my\nfavorite text editor with all-spaces, therefore all-spaces sucks\".\n\nAs for *disk space*? When we can measure cheap drives in sizable\nfractions of *terabytes*, this simply isn't a serious argument.\n\n> > But I still haven't seen any compelling arguments against the \"all space\"\n> > case, other than \"people will screw it up into mixed spaces\", which is really\n> > a straw man, as many multi-platform projects enforced the all-space policy\n> > easily by using a pre-commit hook in maintainers' repository.\n> \n> Hey, you start your own projct, and you can enforce whatever idiotic rules \n> you want to. \n\nYeah, can you believe some projects actually *survive* with an\nall-spaces indentation rule? And ::gasp:: even *thrive*?\n\n> But in the meantime, all-tab indentations are equally good, and are the \n> defacto rule. So *you* are the one who should show compelling arguments \n> for changing, and so far you haven't shown any.\n> \n> Really: what is the problem with hardtabs? Absolutely none.\n\nProblems have been outlined, but since everything for you comes down to\n\"anything that comes between me and microemacs sucks\", rational\ndiscussion breaks down.\n\nThank goodness the git community (not to mention the Linux community!)\nis larger than you; they exist in no small part due to your programming\nskill and initial open-sourcing, but certainly in *spite* of your\npersonality otherwise.\n"},{"id":"56276","messageId":"alpine.LFD.0.999.0710171147190.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"1192645509.6640.21.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T18:54:11Z","receivedAt":"2007-10-17T18:54:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Tom Tobin wrote:\n> \n> Or is \"unix developers\" code for \"my sample size of one\"?\n\nWell, let's put it this way: that \"sample\" is the one that started the \nproject.\n\nI got to pick the license. Are you going to argue about that too? I got to \npick the way I wrote the code. Are you going to continue arguing about \nthat?\n\nThe fact is, I don't see the people arguing for spaces having actually \n*done* anything for git. So why are you arguing?\n\n> Interesting how you waver between \"certain developers\" and \"me\". I'm\n> convinced at this point that your argument comes down to \"I can't use my\n> favorite text editor with all-spaces, therefore all-spaces sucks\".\n\nUmm. And I've *told* you that.\n\nThe whole point is:\n - every single damn editor out there can handle tabs.\n - it's the default\n - end of story.\n\nWhat's so hard to understand? \n\n> As for *disk space*? When we can measure cheap drives in sizable\n> fractions of *terabytes*, this simply isn't a serious argument.\n\nThat disk-space translates into memory usage too, and into just being \ntechnically the *inferior* choice.\n\nHow hard is that to accept? If you have a choice between a technically \nbetter solution, and a technically worse one, why are you arguing for the \nworse one?\n\n> Yeah, can you believe some projects actually *survive* with an\n> all-spaces indentation rule? And ::gasp:: even *thrive*?\n\nHey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that \n*git* should not, the same way the Linux kernel does not and will not.\n\nWhy? Because tabs are better. You (or anybody else) have simply never \ngiven any argument against that very simple argument. You try to push an \ninferior solution.\n\n> Problems have been outlined, but since everything for you comes down to\n> \"anything that comes between me and microemacs sucks\", rational\n> discussion breaks down.\n\nDon't talk about \"rational discussion\", since you don't even *have* any.\n\nThe starting point for any rational decision would be to explain why \nchanging tabs to spaces would actually improve anything at all. And you \nhave yet to show *any* such argument, while I've shown arguments to the \nreverse.\n\nOne big one being: the person who started the project and still actually \n*does* something for it actually cares.\n\nIn contrast, your argument seems to be \"I've not actually done anything, \nbut I want to paint the bikeshed pink\".\n\n\t\tLinus\n"},{"id":"56285","messageId":"1192649598.6640.44.camel@athena","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710171147190.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Tom Tobin","fromEmail":"korpios@korpios.com","sentAt":"2007-10-17T19:33:18Z","receivedAt":"2007-10-17T19:33:18Z","isPatch":false,"sender":{"key":"korpios@korpios.com","avatar":null},"body":"On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:\n> \n> On Wed, 17 Oct 2007, Tom Tobin wrote:\n> > \n> > Or is \"unix developers\" code for \"my sample size of one\"?\n> \n> Well, let's put it this way: that \"sample\" is the one that started the \n> project.\n\nAnd therefore your choices become magically reasonable?\n\n> I got to pick the license. Are you going to argue about that too? I got to \n> pick the way I wrote the code. Are you going to continue arguing about \n> that?\n\nThe way you *wrote* the code is different from deciding how the code\n*should* be written — or is your code set in stone? (Funny, considering\nthat we're talking about a revision control system here.)\n\nAs for the license bit ­— yes, you certainly *did* get to pick the\nlicense. What's your point? We wouldn't even be having this discussion\nif it wasn't open source.\n\n> The fact is, I don't see the people arguing for spaces having actually \n> *done* anything for git. So why are you arguing?\n\nOh, here you pull out the big stick: if you haven't already done\nanything for git, your ideas (as for what to, hmm, do for git) are\nworthless! Err, yeah, great perspective there.\n\n> > Interesting how you waver between \"certain developers\" and \"me\". I'm\n> > convinced at this point that your argument comes down to \"I can't use my\n> > favorite text editor with all-spaces, therefore all-spaces sucks\".\n> \n> Umm. And I've *told* you that.\n> \n> The whole point is:\n> - every single damn editor out there can handle tabs.\n> - it's the default\n> - end of story.\n> \n> What's so hard to understand? \n\nEvery single damn editor out there can handle spaces.\n\nThe \"default\" is project-by-project.\n\nSince you're BD in git-land, yes, your say-so is ultimately\nend-of-story. It doesn't make your argument reasonable.\n\n> > As for *disk space*? When we can measure cheap drives in sizable\n> > fractions of *terabytes*, this simply isn't a serious argument.\n> \n> That disk-space translates into memory usage too, and into just being \n> technically the *inferior* choice.\n> \n> How hard is that to accept? If you have a choice between a technically \n> better solution, and a technically worse one, why are you arguing for the \n> worse one?\n\nThat disk space translates into memory usage exactly *how*? Compiled\ncode? Or the in-memory text while you're editing? The former can't be\nthe issue, and the latter is trivial.\n\nAnd, of course, this still comes up against the *benefits* of\nall-spaces. Benefits which have been mentioned by several people;\nbenefits which you refuse to *acknowledge*, even if they don't sway you.\n\n> > Yeah, can you believe some projects actually *survive* with an\n> > all-spaces indentation rule? And ::gasp:: even *thrive*?\n> \n> Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that \n> *git* should not, the same way the Linux kernel does not and will not.\n> \n> Why? Because tabs are better. You (or anybody else) have simply never \n> given any argument against that very simple argument. You try to push an \n> inferior solution.\n\nUh huh.\n\n> > Problems have been outlined, but since everything for you comes down to\n> > \"anything that comes between me and microemacs sucks\", rational\n> > discussion breaks down.\n> \n> Don't talk about \"rational discussion\", since you don't even *have* any.\n> \n> The starting point for any rational decision would be to explain why \n> changing tabs to spaces would actually improve anything at all. And you \n> have yet to show *any* such argument, while I've shown arguments to the \n> reverse.\n\nYou're being willfully blind here.\n\n> One big one being: the person who started the project and still actually \n> *does* something for it actually cares.\n\nBecause, once again, this makes your arguments correct, doesn't it?\n\n> In contrast, your argument seems to be \"I've not actually done anything, \n> but I want to paint the bikeshed pink\".\n\nBecause, once again, being new makes one incorrect, doesn't it?\n\nYou've essentially demonstrated that git's \"benevolent\" dictator is an\nasshole, and even worse, an irrational asshole. It's one thing to deal\nwith a community member like that; when it's the BD, I think I'll move\nalong elsewhere. Congratulations.\n"},{"id":"56286","messageId":"alpine.LFD.0.999.0710171243060.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"1192649598.6640.44.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T19:44:16Z","receivedAt":"2007-10-17T19:44:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Tom Tobin wrote:\n> > \n> > Well, let's put it this way: that \"sample\" is the one that started the \n> > project.\n> \n> And therefore your choices become magically reasonable?\n\nThey sure as hell automatically become a lot more relevant than YOUR \nchoices, don't they?\n\n> Every single damn editor out there can handle spaces.\n\nYes, and they'll start mixing spaces and tabs when they auto-indent.\n\n\t\tLinus\n"},{"id":"56287","messageId":"200710172147.06025.wielemak@science.uva.nl","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710171147190.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Jan Wielemaker","fromEmail":"wielemak@science.uva.nl","sentAt":"2007-10-17T19:47:05Z","receivedAt":"2007-10-17T19:47:05Z","isPatch":false,"sender":{"key":"wielemak@science.uva.nl","avatar":null},"body":"On Wednesday 17 October 2007 20:54, Linus Torvalds wrote:\n> On Wed, 17 Oct 2007, Tom Tobin wrote:\n> > Or is \"unix developers\" code for \"my sample size of one\"?\n>\n> Well, let's put it this way: that \"sample\" is the one that started the\n> project.\n>\n> I got to pick the license. Are you going to argue about that too? I got to\n> pick the way I wrote the code. Are you going to continue arguing about\n> that?\n>\n> The fact is, I don't see the people arguing for spaces having actually\n> *done* anything for git. So why are you arguing?\n\nPossibly because they do not want to cooperate :-) Anyway, it is mostly\na Unix <-> the rest issue. In the Unix world all tools by default use\n8-spaces per tab and although most of them can be told otherwise, nobody\nbothers. That way at least all code looks the same, regardless of spaces\nor tabs. Many editors are smart enough to create sequences\nN+M for initial indentation to get consistent usage, but even\nif it isn't consistent patch and diff can be told to handle it.\n\nOutside the Unix world there appears to be little standard, so you receive\nfiles with any combination of tab distance, using tabs vs. spaces, etc.\nMost often I have to re-indent them before reading :-(\n\nI guess the most ideal situation is to use only tabs for initial indentation\nand spaces elsewhere, so changing the tab distance gets consistent layout.\nThe drawback is that there is no room for `half indentation', so style\nconventions have to take care of that.\n\nStill, the main developers take the decision. If you don't like it, don't\ncooperate or fork.\n\n\t--- Jan\n"},{"id":"56288","messageId":"alpine.LFD.0.9999.0710171542530.19446@xanadu.home","threadId":"10307","inReplyTo":"1192649598.6640.44.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-17T19:48:31Z","receivedAt":"2007-10-17T19:48:31Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 17 Oct 2007, Tom Tobin wrote:\n\n> On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:\n> > In contrast, your argument seems to be \"I've not actually done anything, \n> > but I want to paint the bikeshed pink\".\n> \n> Because, once again, being new makes one incorrect, doesn't it?\n> \n> You've essentially demonstrated that git's \"benevolent\" dictator is an\n> asshole, and even worse, an irrational asshole. It's one thing to deal\n> with a community member like that; when it's the BD, I think I'll move\n> along elsewhere. Congratulations.\n\nIf you can't overcome your dislike for tabs and accept that this is the \ncoding style for the Git project then please go away.\n\nCan this discussion, rational or not, just stop now?\n\n\nNicolas\n"},{"id":"56289","messageId":"1192650740.6223.24.camel@beauty","threadId":"10307","inReplyTo":"1192649598.6640.44.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Josh England","fromEmail":"jjengla@sandia.gov","sentAt":"2007-10-17T19:52:20Z","receivedAt":"2007-10-17T19:52:20Z","isPatch":false,"sender":{"key":"jjengla@sandia.gov","avatar":null},"body":"On Wed, 2007-10-17 at 14:33 -0500, Tom Tobin wrote:\n> That disk space translates into memory usage exactly *how*? Compiled\n> code? Or the in-memory text while you're editing? The former can't be\n> the issue, and the latter is trivial.\n\nThink compression. Worse yet in my opinion is the bandwidth spike that\nthe larger tarball would create. Estimates earlier in the thread put\nthe difference at upwards of 40MB. Disk space may be cheap, but highly\navailable redundant mirrored disk space is not, and neither is\nbandwidth.\n\n> And, of course, this still comes up against the *benefits* of\n> all-spaces. Benefits which have been mentioned by several people;\n> benefits which you refuse to *acknowledge*, even if they don't sway you.\n\nI think what Linus is trying to say here is this: THE \"BENEFITS\" DO\n*NOT* OUTWEIGH THE DRAWBACKS. Accept it and move on.\n\n> You've essentially demonstrated that git's \"benevolent\" dictator is an\n> asshole, and even worse, an irrational asshole. It's one thing to deal\n> with a community member like that; when it's the BD, I think I'll move\n> along elsewhere. Congratulations.\n\nLovely. Personal attacks are such an effective way to get your point\nacross. You, sir, are a tool. Good riddance.\n\n-JE\n"},{"id":"56291","messageId":"85wstlecxp.fsf@lola.goethe.zz","threadId":"10307","inReplyTo":"alpine.LFD.0.9999.0710171337330.19446@xanadu.home","subject":"Re: On Tabs and Spaces","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-17T19:52:34Z","receivedAt":"2007-10-17T19:52:34Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 17 Oct 2007, David Kastrup wrote:\n>\n>> Luke Lu writes:\n>> \n>> > But I still haven't seen any compelling arguments against the \"all\n>> > space\" case, other than \"people will screw it up into mixed spaces\",\n>> > which is really a straw man, as many multi-platform projects\n>> > enforced the all-space policy easily by using a pre-commit hook in\n>> > maintainers' repository.\n>> \n>> All-space indentation renders the binary delta algorithm git uses for\n>> compression of packs slow and partly inoperative (all sequences of 16\n>> spaces share the same finger print, and the number of identical finger\n>> prints for which the file information is kept is reduced to 64).\n>\n> But sequences of 16 spaces are unlikely to land on 16-byte boundaries \n> all the time in the file so adjacent data to those 16-space blocks will \n> still provide good hashing.\n\nHalf of the three-tab equivalents and all of the four-tab equivalents\ncontain a 16-byte space sequence on the tested boundary.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"56290","messageId":"alpine.LFD.0.999.0710171246500.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"1192649598.6640.44.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T19:53:58Z","receivedAt":"2007-10-17T19:53:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Tom Tobin wrote:\n> \n> And, of course, this still comes up against the *benefits* of\n> all-spaces. Benefits which have been mentioned by several people;\n> benefits which you refuse to *acknowledge*, even if they don't sway you.\n\nI notice how you didn't even list them. Why? Because they don't exist? \n\nSo here's the deal: I claim that \"use hard-tabs, and accept that they are \n8 characters wide\" is a provably working situation. For lots of *large* \nprojects. I'm not some odd-ball person here, I bet that if you go and look \nat any sourceforge entry that is written in C (which is the language we're \ndebating here), you'll find that the ones that use hard-tabs (even if they \nuse spaces for smaller indents) are the vast majority.\n\nSo what's your point? You're pushing something that is provably odd-ball, \nsince almost nobody uses it, and you cannot even state what the huge \nadvantages are, and you claim that I'm the one that ignores them, when it \nis *you* who have refused to acknowledge that there are reasons to *not* \ndo it (one big reason being that there are current existing and \nproductive developers that definitely do *not* want to change - and no, \nit wasn't just me, either).\n\nYour arguments make no sense. So *of*course* they don't sway me.\n\nAnd you know what? I don't much care if you aren't swayed by mine. It's to \nsome degree a matter of taste, and the fact is, if you don't like the \ncurrent git model, you can go away and play with your own model. It *is* \nopen source, after all. \n\nPut another way: if you cannot respect the wishes of the people who have \ndone the work, then I damn well have no reason what-so-ever to respect \n*yours*. \n\n\t\tLinus\n"},{"id":"56293","messageId":"85k5pleb51.fsf@lola.goethe.zz","threadId":"10307","inReplyTo":"1192649598.6640.44.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-17T20:31:22Z","receivedAt":"2007-10-17T20:31:22Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Tom Tobin writes:\n\n> On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:\n>\n>> In contrast, your argument seems to be \"I've not actually done\n>> anything, but I want to paint the bikeshed pink\".\n>\n> Because, once again, being new makes one incorrect, doesn't it?\n>\n> You've essentially demonstrated that git's \"benevolent\" dictator is\n> an asshole, and even worse, an irrational asshole.\n\nYou are doing Junio a harsh injustice here.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"56296","messageId":"Pine.LNX.4.64.0710172207530.25221@racer.site","threadId":"10307","inReplyTo":"1192649598.6640.44.camel@athena","subject":"Re: On Tabs and Spaces","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-17T21:08:30Z","receivedAt":"2007-10-17T21:08:30Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Oct 2007, Tom Tobin wrote:\n\n> On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote:\n> > \n> > On Wed, 17 Oct 2007, Tom Tobin wrote:\n> > > \n> > > Or is \"unix developers\" code for \"my sample size of one\"?\n> > \n> > Well, let's put it this way: that \"sample\" is the one that started the \n> > project.\n> \n> And therefore your choices become magically reasonable?\n\nTom, you have to contribute way more code than you did, in order to be \ntaken seriously with statements as these.\n\nCiao,\nDscho\n"},{"id":"56297","messageId":"20071017232146.4b9e4097@localhost.localdomain","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710171246500.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Christer Weinigel","fromEmail":"christer@weinigel.se","sentAt":"2007-10-17T21:21:46Z","receivedAt":"2007-10-17T21:21:46Z","isPatch":false,"sender":{"key":"christer@weinigel.se","avatar":null},"body":"This is bloody ridiculous, but...\n\nOn Wed, 17 Oct 2007 12:53:58 -0700 (PDT)\nLinus Torvalds wrote:\n\n> So what's your point? You're pushing something that is provably\n> odd-ball, since almost nobody uses it, and you cannot even state what\n> the huge advantages are, and you claim that I'm the one that ignores\n> them, when it is *you* who have refused to acknowledge that there are\n> reasons to *not* do it (one big reason being that there are current\n> existing and productive developers that definitely do *not* want to\n> change - and no, it wasn't just me, either).\n> \n> And you know what? I don't much care if you aren't swayed by mine.\n> It's to some degree a matter of taste, and the fact is, if you don't\n> like the current git model, you can go away and play with your own\n> model. It *is* open source, after all. \n> \n> Put another way: if you cannot respect the wishes of the people who\n> have done the work, then I damn well have no reason what-so-ever to\n> respect *yours*. \n\nI think you would get at lot less argument if you weren't so damn self\nrighteous about it. If you'd just said \"it's a matter of taste and\nhard tabs 8 spaces wide are the way we prefer to do it and that's the\nway we want to keep doing it\" I'd not have any problem with it.\n\nBut when you start claiming that there are no reasons to use all\nspaces, and that it doesn't solve any problems (it definitely does),\nand that all editors work with hard tabs at 8 (which they don't), at\nleast I get a bit frustrated with you. It's very non-respectful of you\nto claim that everyone is stupid that doesn't agree with you and is\njust asking for silly arguments. Yes, I know, you're an opinionated\nbastard and proud of it, but maybe you should tone that down a bit.\n\n(At least I got quite insulted by your Git talk at Google. People\nare not stupid just because they don't agree with you, most of the time\nthey just have different preferences or different goals.)\n\n /Christer (trying to escape from Lilliput)\n"},{"id":"56299","messageId":"k5pll7rb.fsf@blue.sea.net","threadId":"10307","inReplyTo":"E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-10-17T22:02:32Z","receivedAt":"2007-10-17T22:02:32Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Wed 2007-10-17 Michael Witten \n* Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu\n> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n>\n>> But I still haven't seen any compelling arguments against the \"all\n>> space\" case\n>\n> Overhead!\n>\n> If you use 8 spaces instead of one tab,\n> that's using up 7x more space!\n\nSoftware is the right place to worry about optimization. We should trust\nSCM to make proper and efficient deltas. If not, algorithms need\nimprovemnts.\n\nAny cross platform development or electronic exchange is guaranteed to\nbe interpreted correctly when policy enforces \"only spaces\"\n\nAs we have already seen in numerous times in this thread, using tabs\nwill - eventually - be interpreted in some editor, in some display, in\nsome encironment using some tools ... incorrectly or different than the\nauthor intended. Simply because editors are configurable and we cannot\nknow what settings they may have when they load the file in.\n\nThere is no such problem with spaces. \n\nThe storage constraints are insignificant given the disk space vs. cost;\nincluding possibly used compression algorithms in storage or transfers.\n\nJari\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"56300","messageId":"alpine.LFD.0.999.0710171438551.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071017232146.4b9e4097@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T22:03:55Z","receivedAt":"2007-10-17T22:03:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Christer Weinigel wrote:\n> \n> But when you start claiming that there are no reasons to use all\n> spaces, and that it doesn't solve any problems (it definitely does),\n> and that all editors work with hard tabs at 8 (which they don't), at\n> least I get a bit frustrated with you. It's very non-respectful of you\n> to claim that everyone is stupid that doesn't agree with you and is\n> just asking for silly arguments. Yes, I know, you're an opinionated\n> bastard and proud of it, but maybe you should tone that down a bit.\n\nHey, fair enough. \n\nI'm not very tolerant of people who haven't actually done anything, and \nthen come in and say things should be done certain ways. The fact is, code \ntalks, bullshit walks. \n\nAnd bullshit should most definitely not be encouraged. People like that \nshould be discouraged *immediately*. I'm not interested in bikeshed \npainters, I think they should be told so forcefully enough that they \neither shut up or go away. \n\nMaybe it's a character flaw. I'll respect people who do something \ninteresting, but re-implementing CVS (and badly, at that) or talking about \nsyntactic changes to other peoples projects is not going to fill me with \nrespect.\n\nIn short, I'll give respect when somebody is shown to be *worth* that \nrespect. But respect really has to be earned, not just \"assumed\", \notherwise it's pointless.\n\n\t\t\tLinus\n"},{"id":"56301","messageId":"Pine.LNX.4.64.0710172310270.25221@racer.site","threadId":"10307","inReplyTo":"20071017232146.4b9e4097@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-17T22:11:37Z","receivedAt":"2007-10-17T22:11:37Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 17 Oct 2007, Christer Weinigel wrote:\n\n> I think you would get at lot less argument if you weren't so damn self \n> righteous about it.\n\nWhy is it that in this thread, people whom I have heard _nothing_ of \nbefore seem to think this would be a good time to let their opinion be \nheard? Now, _that_ is what I call righteous. Show nothing but opinion.\n\nCiao,\nDscho\n"},{"id":"56303","messageId":"47168E70.4070305@op5.se","threadId":"10307","inReplyTo":"k5pll7rb.fsf@blue.sea.net","subject":"Re: On Tabs and Spaces","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-17T22:36:32Z","receivedAt":"2007-10-17T22:36:32Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jari Aalto wrote:\n> * Wed 2007-10-17 Michael Witten \n> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu\n>> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n>>\n>>> But I still haven't seen any compelling arguments against the \"all\n>>> space\" case\n>> Overhead!\n>>\n>> If you use 8 spaces instead of one tab,\n>> that's using up 7x more space!\n> \n> Software is the right place to worry about optimization. We should trust\n> SCM to make proper and efficient deltas. If not, algorithms need\n> improvemnts.\n> \n> Any cross platform development or electronic exchange is guaranteed to\n> be interpreted correctly when policy enforces \"only spaces\"\n> \n> As we have already seen in numerous times in this thread, using tabs\n> will - eventually - be interpreted in some editor, in some display, in\n> some encironment using some tools ... incorrectly or different than the\n> author intended. Simply because editors are configurable and we cannot\n> know what settings they may have when they load the file in.\n> \n\nAnd simply because nearly all (unix) editors still insert a hard tab\nwhen pressing the tab key, and *mixing* tabs and spaces makes the\nsituation *really* unbearable, one really shouldn't use all spaces.\n\nIt's code, not graphics. If it's really horrible, any editor can be\nconfigured to change the non-default tab-setting back to 8 if that's\nthe problem. Mine's set to 4. Primarily because I think 8 is too\nmuch. Sometimes (roughly once every 2 years), that gives me problem.\nIt's exclusively when someone has consciously mixed tabs and spaces.\nUsing either or *never* gives any problem.\n\n> There is no such problem with spaces. \n> \n\nI beg to differ, for reasons stated multiple times elsewhere in this\nthread.\n\n> The storage constraints are insignificant given the disk space vs. cost;\n\nPerhaps, but it's low-hanging fruit and since all spaces have its issues\ntoo, why not just go with tabs?\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56306","messageId":"20071018011734.7b636141@localhost.localdomain","threadId":"10307","inReplyTo":"Pine.LNX.4.64.0710172310270.25221@racer.site","subject":"Re: On Tabs and Spaces","fromName":"Christer Weinigel","fromEmail":"christer@weinigel.se","sentAt":"2007-10-17T23:17:34Z","receivedAt":"2007-10-17T23:17:34Z","isPatch":false,"sender":{"key":"christer@weinigel.se","avatar":null},"body":"On Wed, 17 Oct 2007 23:11:37 +0100 (BST)\nJohannes Schindelin wrote:\n\n> Hi,\n> \n> On Wed, 17 Oct 2007, Christer Weinigel wrote:\n> \n> > I think you would get at lot less argument if you weren't so damn\n> > self righteous about it.\n> \n> Why is it that in this thread, people whom I have heard _nothing_ of \n> before seem to think this would be a good time to let their opinion\n> be heard? Now, _that_ is what I call righteous. Show nothing but\n> opinion.\n\nI'm not that invisible am I?\n\n cd linux-2.6.22.7\n find . -type f | xargs egrep -il \"weinigel\" | wc -l\n 17\n\nAhh, confirmation, I really do exist. The earliest LSM entry I can find\nfor myself is from 1995:\n\nhttp://www.ibiblio.org/pub/linux/kernel/patches/scanners/hpscan-0.1.1.5.lsm\n\nMmm, nostalgia. :-)\n\nBut yes, I haven't contributed anything to git so far, I mostly lurk\non the mailing list and try to keep up with what's happening to git.\nIn the beginning I sent a few ideas to the list (which quite sadly were\nignored), but unfortunately I've been busy with paying work to do much\nwith git after that. And at work we use Perforce (yuk) or Subversion\n(a lot nicer than Perforce) and privately I use CVS just because I\nstarted using CVS ten years ago and haven't bothered to change. And\nwhen I'm free I prefer to hack on hardware or device drivers instead.\n\nThe reason I wrote my first mail in this thread is that I work in a\ndifferent environment than Linus does and wanted to share that\nexperience. I usually work with embedded programming, where people use\nlots of different editors and in mixed environments. Some people use\nVisual Studio on Windows because that's what they use for host\nprogramming, a lot of embedded development is done in the (almost\ninvariably sucky) IDE that comes with the compilers for the embedded\nCPU, such as Microchips MPLAB or IAR Workbench, Eclipse is becoming\nquite popular for C development, Slickedit is also popular on Windows,\na colleague prefers nedit for some strange reason, and so on. In such a\nheterogeneous environment the easiest way to make sure that people see\nthe same indentation in all editors is to just tell them to use spaces\nfor indentation, and I think that every editor I just mentioned has a\nsetting to do that automatically. Microemacs is the odd one out in\nthat it doesn't support it. And my employers haven't really been\npaying me to go on a crusade for the holy TAB is 8 spaces cause, they\njust want things done, so I've had to settle for a \"good enough\"\nsolution which works most of the time. \n\nSo I just thought it was unfair of Linus to say that \"use spaces\"\ndoesn't solve any problems, in some environments it does. For the\nLinux kernel and Git, it's easier for the maintainer to enforce \nthe coding standards and since Linus and Junio prefer to use hard tabs,\nthat are the rules that people who want to play with their toys\nhave to adhere to.\n\nBTW, how serious is the problem with deltifying when there are a lot of\nspaces that David Kastrup mentioned? It does sound like a quite\nserious problem if it has a big impact on the performance of Git. Git\nisn't only used for the Linux kernel, so there has to be some projects\nthat both use spaces for indentation and use Git out there. Wouldn't\nit be a problem when people put ASCII graphics in comments or just have \ncomments like /*********************************/ in their code?\n\n /Christer\n"},{"id":"56309","messageId":"ejftl3c2.fsf@blue.sea.net","threadId":"10307","inReplyTo":"47168E70.4070305@op5.se","subject":"Re: On Tabs and Spaces","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-10-17T23:38:05Z","receivedAt":"2007-10-17T23:38:05Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Thu 2007-10-18 Andreas Ericsson gmane.comp.version-control.git\n* Message-Id: 47168E70.4070305@op5.se\n> And simply because nearly all (unix) editors still insert a hard tab\n> when pressing the tab key, and *mixing* tabs and spaces makes the\n> situation *really* unbearable, one really shouldn't use all spaces.\n\nThere was no assumption about a particular OS or editors. \n\nThe QA tools will take care of warning or making automatic formatting\nbefore the code is put to SCM. In projects you cannot assume anything\nabout people, their tools or what OS they might use at hand.\n\n>> There is no such problem with spaces. \n>>\n>\n> I beg to differ, for reasons stated multiple times elsewhere in this\n> thread.\n\nConsider:\n\n- Any editor will display the text written in \"all spaces\"\n 100 % the same. Regradless of any viewer or editor used.\n\nBut the same is not true with text that uses tabs (because you\nreally can't know what options the editor is preset / user set /\nregarding the treatment of tabs).\n\nThe score is 1 - 0 for \"all spaces\" in this contest.\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"56311","messageId":"Pine.LNX.4.64.0710180040320.25221@racer.site","threadId":"10307","inReplyTo":"20071018011734.7b636141@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-10-17T23:44:22Z","receivedAt":"2007-10-17T23:44:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 18 Oct 2007, Christer Weinigel wrote:\n\n> On Wed, 17 Oct 2007 23:11:37 +0100 (BST)\n> Johannes Schindelin wrote:\n> \n> > On Wed, 17 Oct 2007, Christer Weinigel wrote:\n> > \n> > > I think you would get at lot less argument if you weren't so damn \n> > > self righteous about it.\n> > \n> > Why is it that in this thread, people whom I have heard _nothing_ of \n> > before seem to think this would be a good time to let their opinion\n> > be heard? Now, _that_ is what I call righteous. Show nothing but\n> > opinion.\n> \n> I'm not that invisible am I?\n> \n> cd linux-2.6.22.7\n> find . -type f | xargs egrep -il \"weinigel\" | wc -l\n> 17\n\nFile or directory not found.\n\nWe are not Linux specific here. Besides, I was talking about _git_ source \ncode, just in case I did not make myself clear.\n\n> [...] and privately I use CVS just because I started using CVS ten years \n> ago and haven't bothered to change.\n\nI wonder why you have to leave your hideout and comment on the source code \nof _git_, then. I mean, why do _you_ care? (It should have become \napparent to you that _we_ care, so it looks even more like you wanted to \ndictate a policy on git, which you have no business with.)\n\nPuzzled, and a little unnerved,\nDscho\n"},{"id":"56313","messageId":"alpine.LFD.0.999.0710171632200.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071018011734.7b636141@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-17T23:53:24Z","receivedAt":"2007-10-17T23:53:24Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Oct 2007, Christer Weinigel wrote:\n> \n> BTW, how serious is the problem with deltifying when there are a lot of\n> spaces that David Kastrup mentioned?\n\nI suspect it works quite well in practice.\n\nBut we've had to tweak the xdiff code before, and the hash calculations \nfor bucket size limits. If somebody actually points out a problem case, we \ncan probably tweak it again.\n\n> Wouldn't it be a problem when people put ASCII graphics in comments or \n> just have comments like /*********************************/ in their \n> code?\n\nIn general, *any* situation where you have tons of character sequences \nthat are the same (and here it's not the characters *themselves* that have \nto be the same - it's the *sequence* that has to be the same, so it's not \nabout repeating the same character over and over per se: it's about \nrepeating a certain block of characters many many times in the source \ncode) will be problematic for pretty much any similarity analysis.\n\nWhy? Because you just have a lot of the same sequence, and to get a good \ndelta you want to find common \"sequences of these sequences\" (call them \nsupersequences) in order to find the biggest common chunk.\n\nSo the badly performing cases for any delta algorithm (and I do want to \npoint out that this has nothing what-so-ever to do with the particular one \nthat git uses) tends to be exactly the ones where you have lots and lots \nof smaller chunks that match in two files, and that then makes it costlier \nto find the *bigger* chunks that are build up of those smaller chunks.\n\nAnd generally you tend to have two situations: you either (a) take *much* \nlonger to find the common areas (they are often quadratic or worse \nalgorithms) or (b) you decide to ignore chunks that are so common that \nthey don't really add any real information when it comes to finding truly \ncommon chunks. Where that second choice generally means that you can miss \nsome cases where you *could* have found a good match for deltification.\n\nIn fact, usually you have a combination of the above two effects: certain \ndeltas may be more expensive to find but there is also a limit that kicks \nin and means that you never spend *too* much time on finding them if the \npattern space is not amenable to it.\n\nWould lots of spaces be such a pattern? I personally doubt it would really \nmatter. In general, source code is easy to delta: the bulk of any common \nsequences in most files will be found by the trivial \"look for common \nsequences in the beginning and the end\". The really *bad* cases tend to be \nrather odd, and often generated files.\n\nSo no, I don't think deltification is a huge deal for spaces. But it does \nboil down to the same kind of issues: if you blow up the source base by \n20%, you often slow down things by 20% or more, simply because there is \nmore data to process at all stages. It simply just slows down everything - \ntotally unnecessarily.\n\n\t\t\tLinus\n"},{"id":"56315","messageId":"20071018023103.5d27ee35@localhost.localdomain","threadId":"10307","inReplyTo":"Pine.LNX.4.64.0710180040320.25221@racer.site","subject":"Re: On Tabs and Spaces","fromName":"Christer Weinigel","fromEmail":"christer@weinigel.se","sentAt":"2007-10-18T00:31:03Z","receivedAt":"2007-10-18T00:31:03Z","isPatch":false,"sender":{"key":"christer@weinigel.se","avatar":null},"body":"On Thu, 18 Oct 2007 00:44:22 +0100 (BST)\nJohannes Schindelin wrote:\n\n> Hi,\n> \n> On Thu, 18 Oct 2007, Christer Weinigel wrote:\n> \n> > I'm not that invisible am I?\n> > \n> > cd linux-2.6.22.7\n> > find . -type f | xargs egrep -il \"weinigel\" | wc -l\n> > 17\n> \n> File or directory not found.\n> \n> We are not Linux specific here. Besides, I was talking about _git_\n> source code, just in case I did not make myself clear.\n\nYou do not have a sense of humor, do you? And you elided the paragraph\nwhere I said that I haven't contributed anything to git so far. :-/\n\n> > [...] and privately I use CVS just because I started using CVS ten\n> > years ago and haven't bothered to change.\n> \n> I wonder why you have to leave your hideout and comment on the source\n> code of _git_, then. I mean, why do _you_ care? (It should have\n> become apparent to you that _we_ care, so it looks even more like you\n> wanted to dictate a policy on git, which you have no business with.)\n\nWhere did I say that I'm not interested in git? If I weren't I\nwouldn't have been reading this mailing list since it was first\ncreated. The reason I don't use git is a lack of time. Professionally\nI usually have no need to use git since my employer doesn't use it.\nOn my own time, I haven't even had time and energy to switch away from\nCVS, even though I ought to have done that years ago. I dabble a bit\nwith git, mercurial, org bitkeeper (or did at least) when I need to\naccess something out on the net which is stored in such a repository,\nbut I haven't switched any of my projects over to using anything else.\n\nI'm definitely interested in git, and it's interesting to read the\nmailing list to see where git is going. And I'd definitely like git to\nmove in a direction where it's usable for me, or even better, where I\ncan recommend it to my (often Windows-only) colleagues. \n\nAnd once again you cut out the part where I said that git is Junio's\nbaby, he decides what goes into the main git tree, and if he says 8\nwide hard tabs, that it is. I haven't argued against that at all. So\nI'm wondering why you are trying to project things I haven't\nsaid on me.\n\n /Christer (pissing contensts are silly, so why the hell am I getting\n involved in one?)\n"},{"id":"56316","messageId":"20071018003256.GA5062@coredump.intra.peff.net","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710170849590.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T00:32:56Z","receivedAt":"2007-10-18T00:32:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 17, 2007 at 08:53:55AM -0700, Linus Torvalds wrote:\n\n> > Well, we just established that all-space is perfect, look-wise.\n> \n> But we also established that an all-space model is not stable, because any \n> unix developers will start adding tabs instead of spaces.\n\nIn what way does an all-space model cause people to accidentally add\ntabs, but an all-tab model does not cause people to accidentally add\nspaces?\n\n-Peff\n"},{"id":"56317","messageId":"alpine.LFD.0.999.0710171753020.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071018003256.GA5062@coredump.intra.peff.net","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-18T00:59:27Z","receivedAt":"2007-10-18T00:59:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Jeff King wrote:\n> \n> In what way does an all-space model cause people to accidentally add\n> tabs, but an all-tab model does not cause people to accidentally add\n> spaces?\n\nIt happens. We do de-spacification in the kernel occasionally when it is \nan annoyance. Usually it shows up in patches, though - exactly because \ncode which adds spaces instead of tabs won't line up correctly in the \ndiff.\n\nSo it doesn't matter *which* one you use (all spaces or all tabs) in that \nsense. But clearly tabs are *way* more common at least in any UNIX \nproject, and tabs really do have the advantage of being smaller.\n\nAnd smaller *is* faster. Do something like this on the kernel:\n\n\tGIT_PAGER= time git grep sched_fair\n\nand then do the same thing with the kernel sources blown up by 20% by \nde-tabification. Guess which one is 20% slower?\n\nAnd whoever said that disk space doesn't matter doesn't know what he is \ntalking about. Disk space most *definitely* matters. Do the above test \nwith a cold-cache case, and think what 20% more IO does to you (or 20% \nless disk cache).\n\nBut no, the size issues are secondary, I'm not claiming anything else. \nAlthough I do suspect that historically, they have been primary, and have \nbeen the thing that has resulted in the fact that tabs are so commonly \nused.\n\n\t\t\tLinus\n"},{"id":"56321","messageId":"20071018024553.GA5186@coredump.intra.peff.net","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710171753020.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T02:45:53Z","receivedAt":"2007-10-18T02:45:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote:\n\n> It happens. We do de-spacification in the kernel occasionally when it is \n> an annoyance. Usually it shows up in patches, though - exactly because \n> code which adds spaces instead of tabs won't line up correctly in the \n> diff.\n\nYou have made this claim several times, and I really don't understand\nit. If I have 8 spaces, then a diff line will have either \" \", \"+\", or\n\"-\" followed by 8 spaces. If I use a hard tab, then the tab will end up\nonly taking up 7 spaces because of the nature of tabs.\n\nThis might matter if I'm comparing non-diff code to diff code. But in a\ndiff, _everything_ is indented by exactly one space, so it all lines up.\nIs there something I'm missing?\n\n> So it doesn't matter *which* one you use (all spaces or all tabs) in that \n> sense.\n\nYes, I agree with that (even with an all-tabs policy, there are still\nmangled and incorrect patches that come in -- and the maintainer rejects\nor fixes them).\n\nWhich was what I was trying to point out with my question (though I was\nalso curious to hear your answer): all-space versus all-tab is largely a\nmatter of preference. And that means that people who want git to change\nto _their_ preference are just being silly.\n\n> And smaller *is* faster. Do something like this on the kernel:\n> \n> \tGIT_PAGER= time git grep sched_fair\n> \n> and then do the same thing with the kernel sources blown up by 20% by \n> de-tabification. Guess which one is 20% slower?\n\nI was about to tell you that you're full of it, but there really is a\nslowdown:\n\n$ cd linux-2.6\n$ GIT_PAGER= time git grep sched_fair >/dev/null\n0.34user 0.94system 0:01.30elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k\n0inputs+0outputs (0major+7548minor)pagefaults 0swaps\n\n$ find . -name .git -prune -o -type f | xargs perl -pi -e 's/\\t/ /g'\n$ git-commit -a -m de-tabify\n$ git-repack -a -d\n$ GIT_PAGER= time git grep sched_fair >/dev/null\n0.42user 1.06system 0:01.54elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k\n0inputs+0outputs (0major+7591minor)pagefaults 0swaps\n\nIt's actually about 16%.\n\n\nGah, I can't believe I've not only been sucked into a tab vs spaces\ndiscussion, but now I've actually wasted time doing a performance\ncomparison on it.\n\nAs an aside, that commit was enough to trigger a \"git-gc --auto\", which\nwas my first experience with it. It's actually kind of annoying\n(especially since I was about to repack -a -d).\n\n-Peff\n"},{"id":"56323","messageId":"20071018030055.GA7218@coredump.intra.peff.net","threadId":"10307","inReplyTo":"Pine.LNX.4.64.0710172002020.10276@asgard.lang.hm","subject":"Re: On Tabs and Spaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T03:00:55Z","receivedAt":"2007-10-18T03:00:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 17, 2007 at 08:03:51PM -0700, david@lang.hm wrote:\n\n>> This might matter if I'm comparing non-diff code to diff code. But in a\n>> diff, _everything_ is indented by exactly one space, so it all lines up.\n>> Is there something I'm missing?\n>\n> if the code uses a tab and the patch uses 8 spaces the two will not line up \n> in the diff becouse in the diff output the tab is 'only 7 spaces;\n>\n> useing one or the other isn't the problem, it's the mixing of the two.\n\nYes, obviously. The people who advocate mixing really _are_ objectively\nwrong. But I was talking about all-spaces versus all-tabs.\n\n-Peff\n"},{"id":"56322","messageId":"Pine.LNX.4.64.0710172002020.10276@asgard.lang.hm","threadId":"10307","inReplyTo":"20071018024553.GA5186@coredump.intra.peff.net","subject":"Re: On Tabs and Spaces","fromName":"","fromEmail":"david@lang.hm","sentAt":"2007-10-18T03:03:51Z","receivedAt":"2007-10-18T03:03:51Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 17 Oct 2007, Jeff King wrote:\n\n> On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote:\n>\n>> It happens. We do de-spacification in the kernel occasionally when it is\n>> an annoyance. Usually it shows up in patches, though - exactly because\n>> code which adds spaces instead of tabs won't line up correctly in the\n>> diff.\n>\n> You have made this claim several times, and I really don't understand\n> it. If I have 8 spaces, then a diff line will have either \" \", \"+\", or\n> \"-\" followed by 8 spaces. If I use a hard tab, then the tab will end up\n> only taking up 7 spaces because of the nature of tabs.\n>\n> This might matter if I'm comparing non-diff code to diff code. But in a\n> diff, _everything_ is indented by exactly one space, so it all lines up.\n> Is there something I'm missing?\n\nif the code uses a tab and the patch uses 8 spaces the two will not line \nup in the diff becouse in the diff output the tab is 'only 7 spaces;\n\nuseing one or the other isn't the problem, it's the mixing of the two.\n\nDavid Lang\n"},{"id":"56325","messageId":"alpine.LFD.0.999.0710171955580.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071018024553.GA5186@coredump.intra.peff.net","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-18T03:13:23Z","receivedAt":"2007-10-18T03:13:23Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Jeff King wrote:\n> \n> You have made this claim several times, and I really don't understand\n> it. If I have 8 spaces, then a diff line will have either \" \", \"+\", or\n> \"-\" followed by 8 spaces. If I use a hard tab, then the tab will end up\n> only taking up 7 spaces because of the nature of tabs.\n> \n> This might matter if I'm comparing non-diff code to diff code. But in a\n> diff, _everything_ is indented by exactly one space, so it all lines up.\n> Is there something I'm missing?\n\nYes. \n\nYou're missing the fact that some people have problems with editors.\n\nSo they add a line, and they add *that* line with the wrong kind of \nindentation. And it shows up among the other lines like this (here the \nwhole patch is indented):\n\n\tdiff --git a/kernel/sched.c b/kernel/sched.c\n\tindex 92721d1..1ecb164 100644\n\t--- a/kernel/sched.c\n\t+++ b/kernel/sched.c\n\t@@ -127,6 +127,7 @@ static inline u32 sg_div_cpu_power(const struct sched_group *sg, u32 load)\n\t static inline void sg_inc_cpu_power(struct sched_group *sg, u32 val)\n\t {\n\t \tsg->__cpu_power += val;\n\t+ wrong indentation here.\n\t \tsg->reciprocal_cpu_power = reciprocal_value(sg->__cpu_power);\n\t }\n\t #endif\n\nand so you see the fact that somebody messed up in the patch itself.\n\nIt actually more often goes the other way: somebody may have messed up \nearlier, but did so *consistently* so it wasn't obvious when looking at \nthe patch. And then somebody fixes one line, and now that one fixed line \nis indented correctly but differently.\n\nWhen it gets *too* bad, we just reindent the whole file, but more \ncommonly when I notice it in a diff, I just edit that particular region \nor even just the diff itself in-place.\n\nGenerally, it seldom comes to even that. Doing a\n\n\tgit grep ' ' -- '*.c'\n\n(that's now eight spaces) returns quite a lot of lines, and it's generally \nnot worth worrying about (not all of them are indentation - people do use \nspaces for lining things up etc - but a lot of it really is just indents \ndone against the coding style).\n\n> I was about to tell you that you're full of it, but there really is a\n> slowdown:\n> [ ... ]\n> It's actually about 16%.\n\nI didn't even time it, and I called it at 20% without even counting any \ntabs. Why? Because it's inevitable!\n\nIt so happens that \"grep\" has a lot of really clever heuristics, so that \nit is actually better at passing over characters that it knows cannot \nstart the pattern you are searching for, so timing \"grep\" is actually \nquite complex in the general case. So I bet that if you had grepped for \nsomething that started with a space, you'd probably have found a bigger \nslowdown. \n\nBut ignore all that complexity, and it really boils down to a really \nsimple principle: bigger data sets are more expensive, and \"linear \nslowdown\" is actually almost the best possible case. Quite often, a bigger \ndata set causes *worse* than a linear slowdown.\n\nIt's very seldom the case that you grow some problem space and performance \nstays the same.\n\n> Gah, I can't believe I've not only been sucked into a tab vs spaces\n> discussion, but now I've actually wasted time doing a performance\n> comparison on it.\n\nWell, performance analysis isn't exactly a \"waste\". That \"git grep\" was \nsomething we spent some time trying to go fast (for example, doing the \nwhole external grep tool thing because that thing is usually optimized to \nh*ll and back - so the execve() overhead is more than worth it).\n\nAnd it's a real workload. Maybe others don't use \"git grep\" quite as much \nas I do, but I do it *all* the time. Some other people probably use ctags \nor something, I personally prefer just a fast git grep.\n\nBut the *exact* same issues will show up for \"simple\" things like \"git \nbisect\". One of the biggest costs of git bisect is actually checking out \nthe source tree. If the source tree is on the order of 20% larger, what \ndoes that mean? \n\nSo it doesn't matter if you have a terabyte disk. Source code size *still* \nmatters.\n\nAnd 20% (or 16%) is more than a lot of other optimizations can help you \nsave!\n\n> As an aside, that commit was enough to trigger a \"git-gc --auto\", which\n> was my first experience with it. It's actually kind of annoying\n> (especially since I was about to repack -a -d).\n\nYeah, I don't think it's wonderful, but it might even be a good thing as a \n\"hey, at least you are aware of the notion of GC now\" kind of introduction \nto people (who then hopefully realize that they don't actually want \nautomatic GC, but rather do it once a week or something).\n\n\t\tLinus\n"},{"id":"56326","messageId":"20071018032307.GA7313@coredump.intra.peff.net","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710171955580.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T03:23:07Z","receivedAt":"2007-10-18T03:23:07Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 17, 2007 at 08:13:23PM -0700, Linus Torvalds wrote:\n\n> Yes. \n> \n> You're missing the fact that some people have problems with editors.\n> \n> So they add a line, and they add *that* line with the wrong kind of \n> indentation. And it shows up among the other lines like this (here the \n> whole patch is indented):\n\nOh. I thought you meant \"if you have an all-spaces policy, your diffs\nwill not look good.\" But what you meant was \"when people screw up your\npolicy by mixing tabs and spaces, your diffs will not look good.\" And\nthat applies equally, whether they are screwing up your all-tabs or\nall-spaces setup (and I remain convinced that no matter what your\npolicy, people _will_ screw it up).\n\nThanks for the clarification.\n\n> It's very seldom the case that you grow some problem space and performance \n> stays the same.\n\nYes. I wondered whether the increased size would really matter here, or\nif it would get lost in the noise of program startup and other\nactivities. But in this case, it really does matter.\n\n> > Gah, I can't believe I've not only been sucked into a tab vs spaces\n> > discussion, but now I've actually wasted time doing a performance\n> > comparison on it.\n> Well, performance analysis isn't exactly a \"waste\". That \"git grep\" was \n\nNo, it's not a waste. In the grand scheme of things, I don't actually\ncare that much about the result, but hey, I think I may be the only\nperson out of this gigantic thread to actually provide _numbers_. :)\n\n> Yeah, I don't think it's wonderful, but it might even be a good thing as a \n> \"hey, at least you are aware of the notion of GC now\" kind of introduction \n> to people (who then hopefully realize that they don't actually want \n> automatic GC, but rather do it once a week or something).\n\nIt would have been nicer if it said something like \"Your repository\nlooks crufty. Running git-gc --auto...\" using whatever terms users would\nbe comfortable with. Instead, it just started with \"Counting objects\"\nand a long wait. I happen to know what that means, but I'm not sure how\na git newbie would react (though it looked _much_ nicer because of\nNico's recent terser progress patches).\n\n-Peff\n"},{"id":"56327","messageId":"loom.20071018T032910-500@post.gmane.org","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Paul Wankadia","fromEmail":"junyer@gmail.com","sentAt":"2007-10-18T03:31:43Z","receivedAt":"2007-10-18T03:31:43Z","isPatch":false,"sender":{"key":"junyer@gmail.com","avatar":null},"body":"Linus Torvalds linux-foundation.org> writes:\n\n> The only sane solution is the one the kernel and git have always used: \n> tabs are 8 spaces wide, and anybody who disagrees can go screw themselves. \n\nI hope and pray that you are parodied on \"South Park\" someday.\n"},{"id":"56328","messageId":"alpine.LFD.0.999.0710172017020.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"20071018030055.GA7218@coredump.intra.peff.net","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-18T03:32:58Z","receivedAt":"2007-10-18T03:32:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Jeff King wrote:\n> \n> Yes, obviously. The people who advocate mixing really _are_ objectively\n> wrong. But I was talking about all-spaces versus all-tabs.\n\nIf you really are all one-or-the-other, then everything is obviously fine, \nand spaces have somewhat stronger guarantees (I say \"somewhat\", because \nthe line-up-guarantee of all-spaces is only guaranteed with fixed-width \nfonts, and hard-tab indents often look nicer in printouts, and are \ngenerally much more flexible in just how wide you make the indent *look*, \nie hard-tabs at least *allow* people to see the indents in different \nways, even if that will potentially mess up any alignment).\n\nBut some mixing is inevitable, and at least in UNIX, the tendency is for \ntabs, not spaces, by default, so tabs have a much higher chance of \n*staying* mostly tabs, while anybody who uses spaces pretty much *will* \nget tabs inserted by just about any programming editor that isn't set up \nfor python.\n\nSo you always get _some_ amount of mixing, exactly because most editors \nwon't show you the difference, and what people aren't aware of, they don't \nthink about. There's no getting away from that, unless you actually \nenforce it with hooks (and in a distributed environment, even that isn't \nreally going to fly, is it?).\n\nAnd if you *do* decide to enforce it with hooks, you now have issues like \nthe fact that some files mustn't do it (autoconvert tabs to spaces in a \nMakefile, and it just stops working!), and others have somewhat subtle \nissues forcing your converter to be somewhat knowledgeable (trivial \nexample: strings that are spread across multiple lines in C..)\n\nIn general, if you do enforce it (which I personally think is not likely a \ngood idea, but hey, it's up to the project), I'd *still* suggest going the \nway of enforcing hard-tabs, not spaces. As mentioned, space does matter, \nbut hardtabs really are \"friendlier\", and if you're a vi user, you can do \na :set tabstop=4 and if that's what you're used to, it will all look \nbetter to you.\n\nIn contrast, all-spaces just sucks. It really has no redeeming values.\n\n\t\tLinus\n"},{"id":"56330","messageId":"alpine.LFD.0.999.0710172102020.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710172017020.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-18T04:17:03Z","receivedAt":"2007-10-18T04:17:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 17 Oct 2007, Linus Torvalds wrote:\n>\n> [..] and if you're a vi user, you can do a ':set tabstop=4'\n\nbtw, don't get me wrong. I think 8-char tabstops are much better, and \nwould much prefer to really teach people not to indent too deeply (because \nsix-deep indents really look ugly as hell with 8-char indents).\n\nSo setting tabstops to smaller values is not something I think is good \npractice, but at least that way you can keep your dirty perversions to \nyourself, and don't have to admit to the world that you molest dogs and \nsmall children and use an inferior tab-stop.\n\nThe rest of the world might notice occsionally when you don't hide your \nnon-indentation tab-uses well enough, of course, but keep to block \ncomments and spaces for non-indentation, and you'll be reasonably safe.\n\nHowever, if I see people actually having indentations six+ deep, I'll know \nthat (a) you're likely a small-tab-misusing-deviant and (b) a horrible \nprogrammer. And then the tab-deviancy is the smaller problem.\n\n(Yes, we do have some cases of six+ deep indentations in the kernel. I'm \nhappy to say that they are fairly rare, and yes, I'm personally convinced \nthat the 8-wide indent level is part of it. It really *does* end up \nencouraging people to split things up and write nested cases as separate \nfunctions etc, because it simply becomes so obvious when things are going \nsouth..)\n\n\t\t\tLinus\n"},{"id":"56331","messageId":"alpine.LFD.0.999.0710172121470.26902@woody.linux-foundation.org","threadId":"10307","inReplyTo":"loom.20071018T032910-500@post.gmane.org","subject":"Re: On Tabs and Spaces","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-10-18T04:22:38Z","receivedAt":"2007-10-18T04:22:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 18 Oct 2007, Paul Wankadia wrote:\n> \n> I hope and pray that you are parodied on \"South Park\" someday.\n\nIsn't that what every person aspires to in the end?\n\nMaybe I should start a kooky religion, then I'd be a shoo-in.\n\n\t\tLinus\n"},{"id":"56332","messageId":"200710180031.54819.dmitry.torokhov@gmail.com","threadId":"10307","inReplyTo":"ejftl3c2.fsf@blue.sea.net","subject":"Re: On Tabs and Spaces","fromName":"Dmitry Torokhov","fromEmail":"dmitry.torokhov@gmail.com","sentAt":"2007-10-18T04:31:54Z","receivedAt":"2007-10-18T04:31:54Z","isPatch":false,"sender":{"key":"dmitry.torokhov@gmail.com","avatar":null},"body":"On Wednesday 17 October 2007, Jari Aalto wrote:\n> - Any editor will display the text written in \"all spaces\"\n> 100 % the same. Regradless of any viewer or editor used.\n> \n> But the same is not true with text that uses tabs (because you\n> really can't know what options the editor is preset / user set /\n> regarding the treatment of tabs).\n> \n> The score is 1 - 0 for \"all spaces\" in this contest.\n> \n\nHow about this - I like tabs because when you removing it you\nneed to hit Backspace just once and don't have to strain your\neyes figuring out \"Did I delete enough? Does it line up now?\"\n\n-- \nDmitry\n"},{"id":"56333","messageId":"20071018043623.GA20054@dpotapov.dyndns.org","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710161214530.6887@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2007-10-18T04:36:23Z","receivedAt":"2007-10-18T04:36:23Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote:\n> The answer is *also* not \"tabs are just for initial code \n> indents\",\n\nUnfortunately, it leads to some problems. For example, you can type:\ngit blame alloc.c\n\n2c1cbec1 (Linus Torvalds 2007-04-16 22:10:19 -0700 21) #define DEFINE_ALLOCATOR(name, type)\t\t\t\t\\\n855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 22) static unsigned int name##_allocs;\t\t\t\t\\\n100c5f3b (Linus Torvalds 2007-04-16 22:11:43 -0700 23) void *alloc_##name##_node(void)\t\t\t\t\t\\\n855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 24) {\t\t\t\t\t\t\t\t\\\n855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 25) \tstatic int nr;\t\t\t\t\t\t\\\n\nand see that the end of line 23 does not look right. Because of that,\nI prefer tabs for initial code indents and spaces in other places. Of\ncourse, my preferences are irrelevant when it comes to someone else's\nproject, and I can easily use whatever style it takes to get things\ndone. It is just that \"use tabs elsewhere and everything will be fine\nas long as you have the standard tab setting\" is not exactly correct.\nThe rest is people's preferences and habits...\n\nDmitry\n"},{"id":"56334","messageId":"20071018044143.GA24043@midwinter.com","threadId":"10307","inReplyTo":"20071018032307.GA7313@coredump.intra.peff.net","subject":"[PATCH] Add a message explaining that automatic GC is about to start","fromName":"","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-18T04:41:43Z","receivedAt":"2007-10-18T04:41:43Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"---\n\nOn Wed, Oct 17, 2007 at 11:23:07PM -0400, Jeff King wrote:\n> It would have been nicer if it said something like \"Your repository\n> looks crufty. Running git-gc --auto...\" using whatever terms users would\n> be comfortable with. Instead, it just started with \"Counting objects\"\n> and a long wait.\n\nAnd as an added bonus, we can tell people how to turn off automatic GC\nand how to invoke it by hand.\n\n builtin-gc.c | 4 ++++\n 1 files changed, 4 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-gc.c b/builtin-gc.c\nindex 23ad2b6..b1159d6 100644\n--- a/builtin-gc.c\n+++ b/builtin-gc.c\n@@ -211,6 +211,10 @@ int cmd_gc(int argc, const char **argv, const char *prefix)\n \t\tprune = 0;\n \t\tif (!need_to_gc())\n \t\t\treturn 0;\n+\t\tfprintf(stderr, \"Packing your repository for optimum \"\n+\t\t\t\"performance. If you would rather run\\n\"\n+\t\t\t\"\\\"git gc\\\" by hand, run \\\"git config gc.auto 0\\\" \"\n+\t\t\t\"to disable automatic cleanup.\\n\");\n \t}\n \n \tif (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD))\n-- \n1.5.3.rc2.4.g726f9\n"},{"id":"56335","messageId":"4716E498.3020601@midwinter.com","threadId":"10307","inReplyTo":"20071018044143.GA24043@midwinter.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-18T04:44:08Z","receivedAt":"2007-10-18T04:44:08Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Sigh... Forgot to add:\n\nSigned-off-by: Steven Grimm \n"},{"id":"56337","messageId":"alpine.LFD.0.9999.0710180049450.19446@xanadu.home","threadId":"10307","inReplyTo":"20071018024553.GA5186@coredump.intra.peff.net","subject":"Re: On Tabs and Spaces","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-18T04:52:59Z","receivedAt":"2007-10-18T04:52:59Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 17 Oct 2007, Jeff King wrote:\n\n> As an aside, that commit was enough to trigger a \"git-gc --auto\", which\n> was my first experience with it. It's actually kind of annoying\n> (especially since I was about to repack -a -d).\n\nWell, you actually touched every files in the tree, and there are about \n22K of them. this, plus the tree objects leading to them, your commit \ncertainly did create an unusual amount of loose objects. Repacking them \nwill inevitably take a wile.\n\n\nNicolas\n"},{"id":"56339","messageId":"20071018045453.GA10825@coredump.intra.peff.net","threadId":"10307","inReplyTo":"alpine.LFD.0.9999.0710180049450.19446@xanadu.home","subject":"Re: On Tabs and Spaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T04:54:53Z","receivedAt":"2007-10-18T04:54:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 12:52:59AM -0400, Nicolas Pitre wrote:\n\n> Well, you actually touched every files in the tree, and there are about \n> 22K of them. this, plus the tree objects leading to them, your commit \n> certainly did create an unusual amount of loose objects. Repacking them \n> will inevitably take a wile.\n\nYes, I know. I wasn't complaining so much about the speed, but rather\nthe behavior of \"git-gc\" running while I was in the middle of trying to\naccomplish something else (I hadn't seen it before, because I generally\nkeep my repos fairly packed).\n\n-Peff\n"},{"id":"56340","messageId":"20071018045520.GA10857@coredump.intra.peff.net","threadId":"10307","inReplyTo":"20071018045453.GA10825@coredump.intra.peff.net","subject":"Re: On Tabs and Spaces","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T04:55:20Z","receivedAt":"2007-10-18T04:55:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 12:54:53AM -0400, Jeff King wrote:\n\n> > Well, you actually touched every files in the tree, and there are about \n> > 22K of them. this, plus the tree objects leading to them, your commit \n> > certainly did create an unusual amount of loose objects. Repacking them \n> > will inevitably take a wile.\n> \n> Yes, I know. I wasn't complaining so much about the speed, but rather\n> the behavior of \"git-gc\" running while I was in the middle of trying to\n> accomplish something else (I hadn't seen it before, because I generally\n> keep my repos fairly packed).\n\nBut if you are trying to say that my case is pathological, then yes.\n\n-Peff\n"},{"id":"56342","messageId":"20071018050158.GA11903@coredump.intra.peff.net","threadId":"10307","inReplyTo":"20071018044143.GA24043@midwinter.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T05:01:58Z","receivedAt":"2007-10-18T05:01:58Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Oct 17, 2007 at 09:41:43PM -0700, koreth@midwinter.com wrote:\n\n> And as an added bonus, we can tell people how to turn off automatic GC\n> and how to invoke it by hand.\n\nI like it, especially with the new progress patches.\n\n-Peff\n"},{"id":"56345","messageId":"20071018051127.GE14735@spearce.org","threadId":"10307","inReplyTo":"20071018050158.GA11903@coredump.intra.peff.net","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-18T05:11:27Z","receivedAt":"2007-10-18T05:11:27Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> On Wed, Oct 17, 2007 at 09:41:43PM -0700, koreth@midwinter.com wrote:\n> \n> > And as an added bonus, we can tell people how to turn off automatic GC\n> > and how to invoke it by hand.\n> \n> I like it, especially with the new progress patches.\n\nMe too. Its in my tree now. :-)\n\n-- \nShawn.\n"},{"id":"56352","messageId":"20071018054246.GA9423@glandium.org","threadId":"10307","inReplyTo":"k5pll7rb.fsf@blue.sea.net","subject":"Re: On Tabs and Spaces","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2007-10-18T05:42:46Z","receivedAt":"2007-10-18T05:42:46Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Thu, Oct 18, 2007 at 01:02:32AM +0300, Jari Aalto wrote:\n> * Wed 2007-10-17 Michael Witten \n> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu\n> > On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n> >\n> >> But I still haven't seen any compelling arguments against the \"all\n> >> space\" case\n> >\n> > Overhead!\n> >\n> > If you use 8 spaces instead of one tab,\n> > that's using up 7x more space!\n> \n> Software is the right place to worry about optimization. We should trust\n> SCM to make proper and efficient deltas. If not, algorithms need\n> improvemnts.\n> \n> Any cross platform development or electronic exchange is guaranteed to\n> be interpreted correctly when policy enforces \"only spaces\"\n> \n> As we have already seen in numerous times in this thread, using tabs\n> will - eventually - be interpreted in some editor, in some display, in\n> some encironment using some tools ... incorrectly or different than the\n> author intended. Simply because editors are configurable and we cannot\n> know what settings they may have when they load the file in.\n> \n> There is no such problem with spaces. \n\nThere is such problem with spaces. A lot of editors will just insert\ntabs to indent a new line when the previous you were typing begins with\nenough spaces, in which case you end up with spaces and tabs mixed all\nthe way. It ends up being worse than all tabs.\n\nMike\n"},{"id":"56356","messageId":"4716F6EB.8060800@op5.se","threadId":"10307","inReplyTo":"20071018023103.5d27ee35@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-18T06:02:19Z","receivedAt":"2007-10-18T06:02:19Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Christer Weinigel wrote:\n> \n> /Christer (pissing contensts are silly, so why the hell am I getting\n> involved in one?)\n\nBecause the right to an opinion is so fundamental to us that when someone\nclaims yours is stupid for reasons you (or me, or anyone) find unfair, we\nstand up and say so. It's not a sign of being stupid. It's a sign of being\nprotective about a very basic democratic right, and oss people are usually\nvery protective about those. Freedom of everything comes easier to people\nthan \"force christianity on the world, but keep your sources open!\".\n\nLinus is definitely not the most polite of people out there. Had he been\nless than top-ranked in the meritocracy he would have been utterly and\ntotally annihilated on several mailing lists a really long time ago. At\nthe same time, he's entitled to his opinion the same way everyone is, and\nhe's entitled to express it any way he wants. When he's *really* off the\nmark, people will tell him so. Or ignore him totally, like an embarrassing\ngrandfather who's just gotten too drunk at the christmas dinner and started\nfondling his grandsons girlfriend. However, the same goes for everyone else,\nand Linus *is* fond of telling people \"so\". If nothing else, it saves\ntime to head off dead ends right at the start.\n\nLinus isn't sacrosankt, just enough of a corner-stone that people will keep\nlistening to him even if he's wildly offending.\n\ntabs-vs-spaces is not, I feel, a discussion that has a great impact in\nthe world, so being \"really off the mark\" is not really possible there.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"56362","messageId":"85zlyhc51q.fsf@lola.goethe.zz","threadId":"10307","inReplyTo":"alpine.LFD.0.999.0710171438551.26902@woody.linux-foundation.org","subject":"Re: On Tabs and Spaces","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-18T06:25:53Z","receivedAt":"2007-10-18T06:25:53Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Linus Torvalds writes:\n\n> Maybe it's a character flaw. I'll respect people who do something\n> interesting, but re-implementing CVS (and badly, at that)\n\nI seem to remember somebody who started out reimplementing Unix, and\nbadly, at that. With the help of many other people, this thing\nfinally became portable to more than i386 and more than AT drives.\nTook quite a long time. The ancient floppy disk code still has the\nrenown of being one of the worst pieces of drivers all around.\n\nIf you find this silly, so do I. That's the point.\n\n> or talking about syntactic changes to other peoples projects is not\n> going to fill me with respect.\n>\n> In short, I'll give respect when somebody is shown to be *worth*\n> that respect. But respect really has to be earned, not just\n> \"assumed\", otherwise it's pointless.\n\nCooperation is easier if one is of the opinion rather that disrespect\nhas to be earned: otherwise you alienate potential contributors before\nthey even had a chance to contribute.\n\nThis difference in approach is one of the things I can't help admiring\nin Junio. And I don't think it is to the detriment of git.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"56367","messageId":"87odewzyj7.fsf@lysator.liu.se","threadId":"10307","inReplyTo":"20071018023103.5d27ee35@localhost.localdomain","subject":"Re: On Tabs and Spaces","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-10-18T07:12:44Z","receivedAt":"2007-10-18T07:12:44Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Christer Weinigel writes:\n\n> I usually have no need to use git since my employer doesn't use it.\n\nThat is actually not true. My employer doesn't use it either (we use\nsvn). But that doesn't stop me from using it all the time. git is an\nexcellent offline svn client.\n\n(hej wingel)\n-- \nDavid Kågedal\n"},{"id":"56368","messageId":"87k5pkzydy.fsf@lysator.liu.se","threadId":"10307","inReplyTo":"47168E70.4070305@op5.se","subject":"Re: On Tabs and Spaces","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2007-10-18T07:15:53Z","receivedAt":"2007-10-18T07:15:53Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Andreas Ericsson writes:\n\n> Jari Aalto wrote:\n>> * Wed 2007-10-17 Michael Witten \n>> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu\n>>> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote:\n>>>\n>>>> But I still haven't seen any compelling arguments against the \"all\n>>>> space\" case\n>>> Overhead!\n>>>\n>>> If you use 8 spaces instead of one tab,\n>>> that's using up 7x more space!\n>>\n>> Software is the right place to worry about optimization. We should trust\n>> SCM to make proper and efficient deltas. If not, algorithms need\n>> improvemnts.\n>>\n>> Any cross platform development or electronic exchange is guaranteed to\n>> be interpreted correctly when policy enforces \"only spaces\"\n>>\n>> As we have already seen in numerous times in this thread, using tabs\n>> will - eventually - be interpreted in some editor, in some display, in\n>> some encironment using some tools ... incorrectly or different than the\n>> author intended. Simply because editors are configurable and we cannot\n>> know what settings they may have when they load the file in.\n>>\n>\n> And simply because nearly all (unix) editors still insert a hard tab\n> when pressing the tab key, and *mixing* tabs and spaces makes the\n> situation *really* unbearable, one really shouldn't use all spaces.\n\nI guess that means that you consider emacs to be an obscure or\nnon-unix editor?\n\nWhen you press TAB while editing program code in emacs it doesn't\ninsert a hard tab. It reindents the current line according to the\nindentation rules. The whitespace at the beginning of the line is\nfilled with spaces and/or tabs, depending on the indent-tabs-mode\nsetting.\n\n-- \nDavid Kågedal\n"},{"id":"56372","messageId":"abqgltqz.fsf@blue.sea.net","threadId":"10307","inReplyTo":"200710180031.54819.dmitry.torokhov@gmail.com","subject":"Re: On Tabs and Spaces","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-10-18T08:19:48Z","receivedAt":"2007-10-18T08:19:48Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Thu 2007-10-18 Dmitry Torokhov \n* Message-Id: 200710180031.54819.dmitry.torokhov@gmail.com\n> On Wednesday 17 October 2007, Jari Aalto wrote:\n>\n>> - Any editor will display the text written in \"all spaces\"\n>> 100 % the same. Regradless of any viewer or editor used.\n>> \n>> But the same is not true with text that uses tabs (because you\n>> really can't know what options the editor is preset / user set /\n>> regarding the treatment of tabs).\n>> \n>> The score is 1 - 0 for \"all spaces\" in this contest.\n>> \n>\n> How about this - I like tabs because when you removing it you\n> need to hit Backspace just once and don't have to strain your\n> eyes figuring out \"Did I delete enough? Does it line up now?\"\n\nFirst I must say that you're right. From user's perspective some things\nare convenient and some things not so convenient; it depends:\n\n a) select an editor where these are no-issues\n b) use an editor that can be configured so that these are no-issues\n c) use the current editor and live by its limitations\n\nI do not speak for any particular project here, just from a general\nperspective[1]:\n\n A project policy QA enforces standards so that everybody can expect\n things to work the same way. The common denominator from view\n perspective (person A, B, C, D ... loads the text into a editor) is\n \"all spaces\". Similarly if code is post processed, all tools can\n expect that there are no surprises (it's all spaces, no combination\n of spaces and tabs).\n\nThe effect of a project policy in general is to enforce standards that\nmay not necessary match everybody's preferences[2].\n\nJari\n\n[1] 99 % of the projects do not use Kernel's 8-wide indentation\nconvention. In all seriously taken editors, the TAB-key is configurable\nto move to specific positions; so called \"tab stops\". Therefore \"hit\nTAB-key to insert tab character\" does not usually apply in coding\ncontext. In coding, the TAB-key is used to control the indentation\nlevel, which is a measure defined in Project policy (coding style).\n\n[2]\nThe tabs vs spaces issue is simular to those of:\n\n- Starting curly brace placement policy: at EOL, or at separate line\n- Identifier naming policy: camelCase vs. dash_names\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"56382","messageId":"4pgolnev.fsf@blue.sea.net","threadId":"10307","inReplyTo":"20071018054246.GA9423@glandium.org","subject":"Re: On Tabs and Spaces","fromName":"Jari Aalto","fromEmail":"jari.aalto@cante.net","sentAt":"2007-10-18T10:36:40Z","receivedAt":"2007-10-18T10:36:40Z","isPatch":false,"sender":{"key":"jari.aalto@cante.net","avatar":"https://avatars.githubusercontent.com/u/34601?v=4"},"body":"* Thu 2007-10-18 Mike Hommey gmane.comp.version-control.git\n* Message-Id: 20071018054246.GA9423@glandium.org\n>> Any cross platform development or electronic exchange is guaranteed to\n>> be interpreted correctly when policy enforces \"only spaces\"\n>\n> There is such problem with spaces. A lot of editors will just insert\n> tabs to indent a new line when the previous you were typing begins with\n> enough spaces, in which case you end up with spaces and tabs mixed all\n> the way. It ends up being worse than all tabs.\n\nThere is \"all-spaces\", but there is no \"all-tabs\" choice.\n\nThe latter will always be mixture of \"spaces and tabs\". We have no\ncontrol how the tabs mix with spaces or vice versa: there could even be\n\"eight spaces\" + proper tabs.\n\nSpeaking generalities (not the git project):\n\n People can't be controlled, or their settings. Therefore there is a\n policy and QA tools to monitor the issues and make things canonical;\n whatever that is for the project.\n\nJari\n\n-- \nWelcome to FOSS revolution: we fix and modify until it shines\n"},{"id":"56388","messageId":"20071018113442.GO18279@machine.or.cz","threadId":"10307","inReplyTo":"abqgltqz.fsf@blue.sea.net","subject":"Re: On Tabs and Spaces","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2007-10-18T11:34:42Z","receivedAt":"2007-10-18T11:34:42Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Oct 18, 2007 at 11:19:48AM +0300, Jari Aalto wrote:\n> [1] 99 % of the projects do not use Kernel's 8-wide indentation\n> convention.\n\n99 % of the list participants sorely wish this thread would die already.\n\n\t\t\t\tPetr \"Pasky\" Baudis\n"},{"id":"56389","messageId":"dbfc82860710180439j6d02651foff9c0c84623a9cf1@mail.gmail.com","threadId":"10307","inReplyTo":"20071018113442.GO18279@machine.or.cz","subject":"Re: On Tabs and Spaces","fromName":"Nikolai Weibull","fromEmail":"now@bitwi.se","sentAt":"2007-10-18T11:39:26Z","receivedAt":"2007-10-18T11:39:26Z","isPatch":false,"sender":{"key":"now@bitwi.se","avatar":"https://gravatar.com/avatar/d9242f067845cf9a72be23e4213c3b6e53492178e5df97372088a441af846133?d=mp&s=160"},"body":"On 10/18/07, Petr Baudis wrote:\n\n> On Thu, Oct 18, 2007 at 11:19:48AM +0300, Jari Aalto wrote:\n\n> > [1] 99 % of the projects do not use Kernel's 8-wide indentation\n> > convention.\n\n> 99 % of the list participants sorely wish this thread would die already.\n\nTo change the subject, let me point out that the percent symbol should\nbe juxtaposed with the number, that is, write \"99%\", not \"99 %\", in\nEnglish.\n\n;-)\n"},{"id":"56399","messageId":"3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com","threadId":"10307","inReplyTo":"20071018044143.GA24043@midwinter.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-10-18T13:52:08Z","receivedAt":"2007-10-18T13:52:08Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote:\n\n> And as an added bonus, we can tell people how to turn off automatic GC\n> and how to invoke it by hand.\n\n> +\t\tfprintf(stderr, \"Packing your repository for optimum \"\n> +\t\t\t\"performance. If you would rather run\\n\"\n> +\t\t\t\"\\\"git gc\\\" by hand, run \\\"git config gc.auto 0\\\" \"\n> +\t\t\t\"to disable automatic cleanup.\\n\");\n\nI'm not sure telling the users how to disable it every time it shows \nup is a good idea. gc --auto exists for the naive user, and \nsuggesting they turn it off each time it happens will just result \nin... people turning it off, leading back to the performance issues \nthat caused the feature to be installed in the first place. Perhaps \na message more along the lines of \"To avoid this, run \"git gc\" \nmanually on a regular basis. See 'git help gc' for more information.\"\n\n~~ Brian\n"},{"id":"56401","messageId":"47176AB9.7010409@midwinter.com","threadId":"10307","inReplyTo":"3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-10-18T14:16:25Z","receivedAt":"2007-10-18T14:16:25Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Brian Gernhardt wrote:\n> I'm not sure telling the users how to disable it every time it shows \n> up is a good idea. gc --auto exists for the naive user, and \n> suggesting they turn it off each time it happens will just result \n> in... people turning it off, leading back to the performance issues \n> that caused the feature to be installed in the first place. Perhaps a \n> message more along the lines of \"To avoid this, run \"git gc\" manually \n> on a regular basis. See 'git help gc' for more information.\"\n\nThat's a good point. Jeff / Shawn, do you agree with that? I'll come up \nwith an alternate patch if so.\n\n-Steve\n"},{"id":"56402","messageId":"alpine.LFD.0.9999.0710181019080.19446@xanadu.home","threadId":"10307","inReplyTo":"3391BADA-B5B4-4A8E-A6C0-42169AFC0331@silverinsanity.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-10-18T14:21:18Z","receivedAt":"2007-10-18T14:21:18Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 18 Oct 2007, Brian Gernhardt wrote:\n\n> \n> On Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote:\n> \n> > And as an added bonus, we can tell people how to turn off automatic GC\n> > and how to invoke it by hand.\n> \n> > +\t\tfprintf(stderr, \"Packing your repository for optimum \"\n> > +\t\t\t\"performance. If you would rather run\\n\"\n> > +\t\t\t\"\\\"git gc\\\" by hand, run \\\"git config gc.auto 0\\\" \"\n> > +\t\t\t\"to disable automatic cleanup.\\n\");\n> \n> I'm not sure telling the users how to disable it every time it shows up is a\n> good idea. gc --auto exists for the naive user, and suggesting they turn it\n> off each time it happens will just result in... people turning it off,\n> leading back to the performance issues that caused the feature to be installed\n> in the first place. Perhaps a message more along the lines of \"To avoid this,\n> run \"git gc\" manually on a regular basis. See 'git help gc' for more\n> information.\"\n\nThis is indeed a good point.\n\nAnd for those who start repacking manually then the automatic repacking \nwill very rarely trigger, reducing the need for turning automatic \nrepacking off anyway.\n\n\nNicolas\n"},{"id":"56421","messageId":"20071018180843.GA11624@sigill.intra.peff.net","threadId":"10307","inReplyTo":"47176AB9.7010409@midwinter.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-18T18:08:44Z","receivedAt":"2007-10-18T18:08:44Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 07:16:25AM -0700, Steven Grimm wrote:\n\n>> installed in the first place. Perhaps a message more along the lines of \n>> \"To avoid this, run \"git gc\" manually on a regular basis. See 'git help \n>> gc' for more information.\"\n>\n> That's a good point. Jeff / Shawn, do you agree with that? I'll come up with \n> an alternate patch if so.\n\nYes, that seems reasonable. I think the most important thing is that\nthey realize that \"git-gc\" is responsible for what is happening. That\nshould allow them to find more information in the documentation if they\nwant (and Brian's suggestion points directly to the documentation, which\nis great).\n\n-Peff\n"},{"id":"56448","messageId":"20071019001648.GO14735@spearce.org","threadId":"10307","inReplyTo":"47176AB9.7010409@midwinter.com","subject":"Re: [PATCH] Add a message explaining that automatic GC is about to start","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T00:16:48Z","receivedAt":"2007-10-19T00:16:48Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Steven Grimm wrote:\n> Brian Gernhardt wrote:\n> >I'm not sure telling the users how to disable it every time it shows \n> >up is a good idea. gc --auto exists for the naive user, and \n> >suggesting they turn it off each time it happens will just result \n> >in... people turning it off, leading back to the performance issues \n> >that caused the feature to be installed in the first place. Perhaps a \n> >message more along the lines of \"To avoid this, run \"git gc\" manually \n> >on a regular basis. See 'git help gc' for more information.\"\n> \n> That's a good point. Jeff / Shawn, do you agree with that? I'll come up \n> with an alternate patch if so.\n\nArrgh. I already have the original patch in this thread in my master\nso I can't rewind it. But yes, the argument Brian is making above\nmakes a lot of sense and I like his proposed message even better\nthan what I've already applied.\n\nA patch against spearce/master to revert the prior message and insert\nsomething that is perhaps more reasonable would be most appreciated.\n\n-- \nShawn.\n"},{"id":"56458","messageId":"20071019011211.GC3290@coredump.intra.peff.net","threadId":"10307","inReplyTo":"20071019001648.GO14735@spearce.org","subject":"[PATCH] git-gc: improve wording of --auto notification","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T01:12:11Z","receivedAt":"2007-10-19T01:12:11Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The previous message had too much of a \"boy, you should\nreally turn off this annoying gc\" flair to it. Instead,\nlet's make sure the user understands what is happening, that\nthey can run it themselves, and where to find more info.\n\nSuggested by Brian Gernhardt.\n\nSigned-off-by: Jeff King \n---\n\nShawn said:\n> A patch against spearce/master to revert the prior message and insert\n> something that is perhaps more reasonable would be most appreciated.\n\nGeez, you really _are_ the maintainer now, prodding your minions to\nwrite trivial patches for you. :) I don't see any point in reverting the\nother patch separately, since we can just improve the message.\n\nI tried not to use the word \"avoid\" since I think we don't want to imply\nthat auto-gc sucks. It doesn't, but some people might prefer to run it\nmanually, and we should let them know it's an option. I'm open to\nwording improvements.\n\n builtin-gc.c | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-gc.c b/builtin-gc.c\nindex f99b212..3a2ca4f 100644\n--- a/builtin-gc.c\n+++ b/builtin-gc.c\n@@ -206,9 +206,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix)\n \t\tif (!need_to_gc())\n \t\t\treturn 0;\n \t\tfprintf(stderr, \"Packing your repository for optimum \"\n-\t\t\t\"performance. If you would rather run\\n\"\n-\t\t\t\"\\\"git gc\\\" by hand, run \\\"git config gc.auto 0\\\" \"\n-\t\t\t\"to disable automatic cleanup.\\n\");\n+\t\t\t\"performance. You may also\\n\"\n+\t\t\t\"run \\\"git gc\\\" manually. See \"\n+\t\t\t\"\\\"git help gc\\\" for more information.\\n\");\n \t} else {\n \t\t/*\n \t\t * Use safer (for shared repos) \"-A\" option to\n-- \n1.5.3.4.1249.g895be-dirty\n"},{"id":"56460","messageId":"20071019012430.GT14735@spearce.org","threadId":"10307","inReplyTo":"20071019011211.GC3290@coredump.intra.peff.net","subject":"Re: [PATCH] git-gc: improve wording of --auto notification","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-10-19T01:24:30Z","receivedAt":"2007-10-19T01:24:30Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> Shawn said:\n> > A patch against spearce/master to revert the prior message and insert\n> > something that is perhaps more reasonable would be most appreciated.\n> \n> Geez, you really _are_ the maintainer now, prodding your minions to\n> write trivial patches for you. :)\n\nHeh. But didn't I just post a different trivial patch to the\nmailing list not 15 minutes ago? :-)\n\n> I don't see any point in reverting the\n> other patch separately, since we can just improve the message.\n\nI agree. No point in pissing in the snow multiple times over a\nsimple language change. I was perhaps a little too aggressive in\napplying Steven's first patch. Which I also now see git-am actually\nsplit the From line incorrectly and doesn't actually show Steven's\nname in the author field. Arrgh.\n \n> I tried not to use the word \"avoid\" since I think we don't want to imply\n> that auto-gc sucks. It doesn't, but some people might prefer to run it\n> manually, and we should let them know it's an option. I'm open to\n> wording improvements.\n\nI think what you have is many times better. It doesn't tell the\nuser that they can prevent having this activate at the wrong time\nby just running git-gc every so often, but if the message (and\nthe subsequent packing itself) is annoying they'll read the manual\nentry and hopefully figure that out on their own.\n \n> \t\tfprintf(stderr, \"Packing your repository for optimum \"\n> +\t\t\t\"performance. You may also\\n\"\n> +\t\t\t\"run \\\"git gc\\\" manually. See \"\n> +\t\t\t\"\\\"git help gc\\\" for more information.\\n\");\n\n-- \nShawn.\n"},{"id":"56461","messageId":"20071019012608.GA6403@coredump.intra.peff.net","threadId":"10307","inReplyTo":"20071019012430.GT14735@spearce.org","subject":"Re: [PATCH] git-gc: improve wording of --auto notification","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-10-19T01:26:08Z","receivedAt":"2007-10-19T01:26:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 18, 2007 at 09:24:30PM -0400, Shawn O. Pearce wrote:\n\n> I think what you have is many times better. It doesn't tell the\n> user that they can prevent having this activate at the wrong time\n> by just running git-gc every so often, but if the message (and\n> the subsequent packing itself) is annoying they'll read the manual\n> entry and hopefully figure that out on their own.\n\nYes, I tried many wordings of \"this is annoying and you want to avoid\nit,\" but explaining the situation takes way too much time for such a\ncommonly seen message. And I think some people will actually prefer it\nthat way.\n\nBTW, the git-gc manpage needs some cleanup. Patches to follow.\n\n-Peff\n"},{"id":"56703","messageId":"200710201554.16576.robin.rosenberg.lists@dewire.com","threadId":"10307","inReplyTo":"634393B0-734A-4884-93E3-42F7D3CB157F@mit.edu","subject":"Re: On Tabs and Spaces","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-10-20T13:54:16Z","receivedAt":"2007-10-20T13:54:16Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"tisdag 16 oktober 2007 skrev Michael Witten:\n> What are the rules about tabs and spaces in source code?\n> \n> I'm having a terrible time with formatting,\n> especially in the perl scripts; there is a\n> mix of spaces and tabs.\n> \n> from what I can deduce, single tabs are used\n> to introduce the equivalent of 8 spaces while\n> 4 explicit spaces are used for half a tab.\n\nA looong time ago I worked with a system that did not have *this* problem. \nThe code had a straight left margin. No indent. The code was initially written \njust after the origin of time_t (content, not name) and that it was written \non punched cards probably explains the left margin, efter all you can indent \nthe cards if you like to.\n\nI \"accidentally\" did indent code once, but only once, since I got a lot of \ncomplains from others about not following coding standards. My solution was \nto write a Brief macro to indent the code before working on it and undent \nbefore submitting my work to test. We never had a discussion on tabs vs \nspaces.\n\nBtw, some of that code was \"logically\" indented 22 levels. I'm still amazed \natt those long sheets of code people annotated with pencil to discover the \nlogical structure.\n\nSo it is possble to simply not care about tabs and spaces, except where\nthere is a syntactic difference.\n\nFast-formward twenty years and back to the topic.\n\nI think it is ok to start or end a *big* series of changes with a re-format \npatch, iff the series already introduces a *lot* of changes. \n\nIn the previously submitted and rejected patch to cvsexportcommit this\nwas not the case, I rewrote it heavily and that would have been a window\nfor for reformatting, but I didn't see a need, probably because I used emacs\nand probably the original author too. Now I realize the file *is* actually \nindented inconsistently. Add to that that I am responsible for some of it. \nNext person to do any major work on it should submit a fix-indentation patch \nvery much like the one MIchael did. The problem with reviewing such patches\nstill exists, it is not possible to just read such patches, one has to apply \nthem and verify them with other tools.\n\nI've been through enough many bracket and indentation discussions to see that \nit really doesn't matter as much what style is used as long as the same style \nis used throughout a whole source file. There are some coding styles that \nworks bad with the patch/apply style submitting code, but those are not an \nissue here.\n\nAs for TAB size. The most authoritative read \"stupid\") programs on the issue, \ni.e. cat (unix) and type (dos/windows) agree that tab stops are located at \nevery eight position starting (8,16 etc).\n\nAttached is an updated version of a script I've been using lately to clean up \ncommits. First it only removed trailing whitespace, but after this thread I \nchanged it to (try to) tabify changes. Should we use such scripts more \nactively to root out inconsistencies a patch at a time?\n\n-- robin\n"},{"id":"56796","messageId":"buoprz7izr8.fsf@dhapc248.dev.necel.com","threadId":"10307","inReplyTo":"dbfc82860710180439j6d02651foff9c0c84623a9cf1@mail.gmail.com","subject":"Re: On Tabs and Spaces","fromName":"Miles Bader","fromEmail":"miles.bader@necel.com","sentAt":"2007-10-22T03:39:39Z","receivedAt":"2007-10-22T03:39:39Z","isPatch":false,"sender":{"key":"miles.bader@necel.com","avatar":"https://gravatar.com/avatar/be062d4050eb88e04229cbdb60f803e1bd647923a015996c2439e76f23e336a7?d=mp&s=160"},"body":"\"Nikolai Weibull\" writes:\n> To change the subject, let me point out that the percent symbol should\n> be juxtaposed with the number, that is, write \"99%\", not \"99 %\", in\n> English.\n\nHmm, but what if one uses a tab?\n\n-miles\n\n-- \nMy books focus on timeless truths. -- Donald Knuth\n"}]}