* On Tabs and Spaces @ 2007-10-16 6:45 Michael Witten 2007-10-16 7:04 ` Shawn O. Pearce ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Michael Witten @ 2007-10-16 6:45 UTC (permalink / raw) To: git What are the rules about tabs and spaces in source code? I'm having a terrible time with formatting, especially in the perl scripts; there is a mix of spaces and tabs. from what I can deduce, single tabs are used to introduce the equivalent of 8 spaces while 4 explicit spaces are used for half a tab. I would recommend using all spaces, but the C code seems to prefer all tabs. In any case, some kind of standards need to be set, because no one is following anything curr- ently. Sincerely, Michael Witten ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 6:45 On Tabs and Spaces Michael Witten @ 2007-10-16 7:04 ` Shawn O. Pearce 2007-10-16 7:27 ` Michael Witten 2007-10-16 8:30 ` Adam Piatyszek 2007-10-20 13:54 ` Robin Rosenberg 2 siblings, 1 reply; 100+ messages in thread From: Shawn O. Pearce @ 2007-10-16 7:04 UTC (permalink / raw) To: Michael Witten; +Cc: git Michael Witten <mfwitten@MIT.EDU> wrote: > What are the rules about tabs and spaces in source code? > > I'm having a terrible time with formatting, > especially in the perl scripts; there is a > mix of spaces and tabs. > > from what I can deduce, single tabs are used > to introduce the equivalent of 8 spaces while > 4 explicit spaces are used for half a tab. The C code is all tabs, with the tabs set at 8 spaces, but the actual tab width isn't too important here as we never use the tab for alignment beyond the left indent. The bulk of the Perl/shell is also done that way, but you may run into a place where it isn't. In which case try to match the existing identation within that block as best as you can so the diff is minimal and the resulting file still indents just as good/bad as it did before. You may also consider submitting a whitespace correction patch in front of your actual code change to correct the offending part of the file, but every line you touch is that much more work for your peers to review and test. In short changing code is bad unless there is a really compelling reason... -- Shawn. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 7:04 ` Shawn O. Pearce @ 2007-10-16 7:27 ` Michael Witten 2007-10-16 17:20 ` Andreas Ericsson 0 siblings, 1 reply; 100+ messages in thread From: Michael Witten @ 2007-10-16 7:27 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: git On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote: > The C code is all tabs, with the tabs set at 8 spaces, but the > actual tab width isn't too important here as we never use the tab > for alignment beyond the left indent. Consider this from diff-lib.c: > /* A file entry went away or appeared */ > static void diff_index_show_file(struct rev_info *revs, > const char *prefix, > struct cache_entry *ce, > unsigned char *sha1, unsigned int mode) > { > diff_addremove(&revs->diffopt, prefix[0], ntohl(mode), > sha1, ce->name, NULL); > } There are mixed tabs and spaces for alignment. I suppose I'll be fine if I just set tab widths to 8. But 8 spaces! Good Lord. ;-) I really hate tabs. Thanks, Michael Witten ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 7:27 ` Michael Witten @ 2007-10-16 17:20 ` Andreas Ericsson 2007-10-16 17:40 ` Sam Ravnborg 0 siblings, 1 reply; 100+ messages in thread From: Andreas Ericsson @ 2007-10-16 17:20 UTC (permalink / raw) To: Michael Witten; +Cc: Shawn O. Pearce, git Michael Witten wrote: > On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote: > >> The C code is all tabs, with the tabs set at 8 spaces, but the >> actual tab width isn't too important here as we never use the tab >> for alignment beyond the left indent. > > Consider this from diff-lib.c: > >> /* A file entry went away or appeared */ >> static void diff_index_show_file(struct rev_info *revs, >> const char *prefix, >> struct cache_entry *ce, >> unsigned char *sha1, unsigned int mode) >> { >> diff_addremove(&revs->diffopt, prefix[0], ntohl(mode), >> sha1, ce->name, NULL); >> } > > There are mixed tabs and spaces for alignment. > Function declarations don't count ;-) > I suppose I'll be fine if I just set tab widths to 8. > But 8 spaces! Good Lord. ;-) > > I really hate tabs. > Well, using hard tabs is the only way we can let everyone have different levels of indentation while still having things look sort of sane. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 17:20 ` Andreas Ericsson @ 2007-10-16 17:40 ` Sam Ravnborg 2007-10-16 23:09 ` Petr Baudis 0 siblings, 1 reply; 100+ messages in thread From: Sam Ravnborg @ 2007-10-16 17:40 UTC (permalink / raw) To: Andreas Ericsson; +Cc: Michael Witten, Shawn O. Pearce, git General comment about the <tab> versus spaces debate. The root problem is stupid editors that does not show when a tab is used and when spaces are used. So people continue to mix tabs and spaces. In linux people generally think that 8 aligned spaces equal a tab which is IMHO stupid. Tabs should be used for indent and not general alignment. Consider: <tab>if (some long condition that <tab>....&& spans two lines) { <tab><tab>my_private_printf("bla bla bla" <tab><tab>.................."more bla bla\n"); <tab><tab>} This will look good and align "more bla bla\n" as intended no matter your tab setting. But replacing the 8 spaces with a tab will cause it to look bad. And using tabs let me use the tabsetting I like (8) and other use the tab setting they like (2,3,4,5,6,7) and all is good. And why a tab is 8 spaces and in considered good. Thats to teach people to write small independent functions that does _one_ thing and does it well. Mega functions with 6 times indent or more usually needs to be breaked up anyway. Sam ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 17:40 ` Sam Ravnborg @ 2007-10-16 23:09 ` Petr Baudis 2007-10-17 3:41 ` David 0 siblings, 1 reply; 100+ messages in thread From: Petr Baudis @ 2007-10-16 23:09 UTC (permalink / raw) To: Sam Ravnborg; +Cc: Andreas Ericsson, Michael Witten, Shawn O. Pearce, git On Tue, Oct 16, 2007 at 07:40:26PM +0200, Sam Ravnborg wrote: > Tabs should be used for indent and not general alignment. > > Consider: > <tab>if (some long condition that > <tab>....&& spans two lines) { > <tab><tab>my_private_printf("bla bla bla" > <tab><tab>.................."more bla bla\n"); > <tab><tab>} > > This will look good and align "more bla bla\n" as > intended no matter your tab setting. > But replacing the 8 spaces with a tab will > cause it to look bad. I'd so much love to have this and sometimes do this even manually, but does anyone have an idea how to make vim do this for me? I never got around to investigate this in depth or possibly make a patch... -- Petr "Pasky" Baudis Early to rise and early to bed makes a male healthy and wealthy and dead. -- James Thurber ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 23:09 ` Petr Baudis @ 2007-10-17 3:41 ` David 2007-10-17 11:32 ` Andy Parkins 0 siblings, 1 reply; 100+ messages in thread From: David @ 2007-10-17 3:41 UTC (permalink / raw) To: Petr Baudis; +Cc: git On 10/16/07, Petr Baudis <pasky@suse.cz> wrote: > On Tue, Oct 16, 2007 at 07:40:26PM +0200, Sam Ravnborg wrote: > > Tabs should be used for indent and not general alignment. > > > > Consider: > > <tab>if (some long condition that > > <tab>....&& spans two lines) { > > <tab><tab>my_private_printf("bla bla bla" > > <tab><tab>.................."more bla bla\n"); > > <tab><tab>} > > > > This will look good and align "more bla bla\n" as > > intended no matter your tab setting. > > But replacing the 8 spaces with a tab will > > cause it to look bad. > > I'd so much love to have this and sometimes do this even manually, but > does anyone have an idea how to make vim do this for me? I never got > around to investigate this in depth or possibly make a patch... > > -- > Petr "Pasky" Baudis > Early to rise and early to bed makes a male healthy and wealthy and dead. > -- James Thurber Hello I use both vim and emacs so I must be weird. Anyways, here's some useful vim settings that I've come across: set tabstop=8 set softtabstop=8 set shiftwidth=8 set noexpandtab set list set listchars=<tab>:.\ The last two are extremely useful, especially if you're hacking on python. That's listchars=(less-than)tab(greater-than)(colon)(dot)(backslash)(space) (don't forget the space!). That makes vim display tabs with a "." indicator, so you have a very clear view of when tabs are in use. This has helped me countless times. You can use any character in there instead of dot. I actually use an extended ascii character since it looks nicer but I didn't want to risk email mangling it. -- David ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 3:41 ` David @ 2007-10-17 11:32 ` Andy Parkins 0 siblings, 0 replies; 100+ messages in thread From: Andy Parkins @ 2007-10-17 11:32 UTC (permalink / raw) To: git; +Cc: David On Wednesday 2007 October 17, David wrote: > The last two are extremely useful, especially if you're hacking on > python. That's > listchars=(less-than)tab(greater-than)(colon)(dot)(backslash)(space) > (don't forget the space!). On the subject of high-ascii chars. Here's my favourite for your .vimrc execute 'set listchars+=tab:'.nr2char(187).nr2char(183) 187 is the "significantly greater than" symbol and 183 is a central dot. i.e. every character of a tab is non-space. The actual characters used aren't actually the point I wanted to make; the thing here is that two non-space characters are used, so every column occupied by the tab is visible - this makes it very easy to see where tabs end and spaces begin. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 6:45 On Tabs and Spaces Michael Witten 2007-10-16 7:04 ` Shawn O. Pearce @ 2007-10-16 8:30 ` Adam Piatyszek 2007-10-16 9:04 ` Lars Hjemli 2007-10-20 13:54 ` Robin Rosenberg 2 siblings, 1 reply; 100+ messages in thread From: Adam Piatyszek @ 2007-10-16 8:30 UTC (permalink / raw) To: Michael Witten; +Cc: git * Michael Witten [16 X 2007 08:45]: > What are the rules about tabs and spaces in source code? Following this topic, I am kindly asking for some tips on configuring Emacs and Vim to follow the rules used for Git and kernel code indentation/alignment. Thanks in advance! BR, /Adam -- .:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:. .:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 8:30 ` Adam Piatyszek @ 2007-10-16 9:04 ` Lars Hjemli 2007-10-16 10:16 ` Adam Piatyszek 0 siblings, 1 reply; 100+ messages in thread From: Lars Hjemli @ 2007-10-16 9:04 UTC (permalink / raw) To: Adam Piatyszek; +Cc: Michael Witten, git On 10/16/07, Adam Piatyszek <ediap@users.sourceforge.net> wrote: > I am kindly asking for some tips on configuring > Emacs and Vim to follow the rules used for Git and kernel code > indentation/alignment. >From http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle;h=7f1730f1a1ae2e9a6f368bdb10ff65f4568863d5;hb=HEAD (defun linux-c-mode () "C mode with adjusted defaults for use with the Linux kernel." (interactive) (c-mode) (c-set-style "K&R") (setq tab-width 8) (setq indent-tabs-mode t) (setq c-basic-offset 8)) And to use this only in a specific directory: (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode) auto-mode-alist)) -- larsh ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 9:04 ` Lars Hjemli @ 2007-10-16 10:16 ` Adam Piatyszek 2007-10-16 15:26 ` Jeffrey C. Ollie 0 siblings, 1 reply; 100+ messages in thread From: Adam Piatyszek @ 2007-10-16 10:16 UTC (permalink / raw) To: Lars Hjemli; +Cc: Michael Witten, git * Lars Hjemli [16 X 2007 11:04]: >>From http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/CodingStyle;h=7f1730f1a1ae2e9a6f368bdb10ff65f4568863d5;hb=HEAD > > (defun linux-c-mode () > "C mode with adjusted defaults for use with the Linux kernel." > (interactive) > (c-mode) > (c-set-style "K&R") > (setq tab-width 8) > (setq indent-tabs-mode t) > (setq c-basic-offset 8)) > > > And to use this only in a specific directory: > > (setq auto-mode-alist (cons '("/usr/src/linux.*/.*\\.[ch]$" . linux-c-mode) > auto-mode-alist)) Thanks! But it seems that the above settings are still imperfect, since they mixes tabs and spaces when aligning. For instance: int some_function(int some_variable) { <T> int result; <T> result = execute_another_function(some_variable, <T> <T> <T> <T> <T> ..other_variable); <T> return result; } <T> - represents tab here, `.' - space And if one change the tab size, it will result in a messy alignment in line 5. I guess there is no ideal solution for this in Emacs. BR, /Adam -- .:. Adam Piatyszek - "ediap" .:. JID: ediap(at)jabber.org .:. .:. ediap(at)users.sourceforge.net .:. PGP key ID: 0x1F115CCB .:. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 10:16 ` Adam Piatyszek @ 2007-10-16 15:26 ` Jeffrey C. Ollie 2007-10-16 15:51 ` Michael Witten 2007-10-16 17:23 ` Andreas Ericsson 0 siblings, 2 replies; 100+ messages in thread From: Jeffrey C. Ollie @ 2007-10-16 15:26 UTC (permalink / raw) To: Adam Piatyszek; +Cc: Lars Hjemli, Michael Witten, git [-- Attachment #1: Type: text/plain, Size: 437 bytes --] On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote: > > And if one change the tab size, it will result in a messy alignment in > line 5. Which is why one should never should change the tab size from anything but 8. > I guess there is no ideal solution for this in Emacs. Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-mode nil)". This will force emacs to always use spaces to indent. Jeff [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 15:26 ` Jeffrey C. Ollie @ 2007-10-16 15:51 ` Michael Witten 2007-10-16 17:06 ` Jari Aalto 2007-10-16 17:23 ` Andreas Ericsson 1 sibling, 1 reply; 100+ messages in thread From: Michael Witten @ 2007-10-16 15:51 UTC (permalink / raw) To: Jeffrey C. Ollie; +Cc: git On 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote: > Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs- > mode > nil)". This will force emacs to always use spaces to indent. That's part of the problem to begin with: people are using both way of indentation. I suggest this not be allowed, or that it be the only way of indenting. However, 8 spaces per tab is a lot of wasted information to be bandying about. Michael Witten ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 15:51 ` Michael Witten @ 2007-10-16 17:06 ` Jari Aalto 2007-10-16 19:20 ` Linus Torvalds 0 siblings, 1 reply; 100+ messages in thread From: Jari Aalto @ 2007-10-16 17:06 UTC (permalink / raw) To: git * Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU> * Message-Id: B2F6DB0C-4EFE-4C56-8E7A-31820320CA02 AT mit.edu > On 16 Oct 2007, at 11:26:07 AM, Jeffrey C. Ollie wrote: > >> Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs- >> mode >> nil)". This will force emacs to always use spaces to indent. > > However, 8 spaces per tab is a lot of wasted > information to be bandying about. Spaces are guaranteed to interpreted correctly in all environments. TABs are the source of too many problems. Jari -- Welcome to FOSS revolution: we fix and modify until it shines ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 17:06 ` Jari Aalto @ 2007-10-16 19:20 ` Linus Torvalds 2007-10-16 19:36 ` Mike Hommey ` (4 more replies) 0 siblings, 5 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-16 19:20 UTC (permalink / raw) To: Jari Aalto; +Cc: git On Tue, 16 Oct 2007, Jari Aalto wrote: > * Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU> > > > > However, 8 spaces per tab is a lot of wasted > > information to be bandying about. > > Spaces are guaranteed to interpreted correctly in all environments. TABs > are the source of too many problems. No. Tabs are 8 spaces wide. Live with it. It's the only sane solution. The fact is, people do mix the two. No ifs, buts or maybes about it. Even in the absense of any actual *spaces*, the size of a tab matters, since you can - and do - have two separately indented things (the initial indentation, and then things like comments being indented separately). The only sane solution is the one the kernel and git have always used: tabs are 8 spaces wide, and anybody who disagrees can go screw themselves. If you don't have 8-character tabs, you *will* get odd indentation. And no, the answer is not to say "don't use tabs at all" and replace them by spaces. The answer is *also* not "tabs are just for initial code indents", because not only will most sane editors never even show the difference, it's simply not how people work. So such a rule about invisible things doesn't work. People who want to be contrary, and have a 2-character-wide tab only have themselves to blame. It's THEIR problem, not somethign that is even worth trying to address. If there are problems with people having small screens, that is damn well not about TAB, it's about code being way too deeply indented, and smaller indents are absolutely *not* the answer - they are part of the damn problem to begin with. The fact that some projects have encouraged bad coding style and *insane* tab values is not a git problem. We should teach people to do *better*, not become worse just because others have done idiotic things. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:20 ` Linus Torvalds @ 2007-10-16 19:36 ` Mike Hommey 2007-10-16 19:47 ` Linus Torvalds 2007-10-16 20:18 ` Tom Tobin ` (3 subsequent siblings) 4 siblings, 1 reply; 100+ messages in thread From: Mike Hommey @ 2007-10-16 19:36 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jari Aalto, git On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote: > > > On Tue, 16 Oct 2007, Jari Aalto wrote: > > > * Tue 2007-10-16 Michael Witten <mfwitten AT MIT.EDU> > > > > > > However, 8 spaces per tab is a lot of wasted > > > information to be bandying about. > > > > Spaces are guaranteed to interpreted correctly in all environments. TABs > > are the source of too many problems. > > No. > > Tabs are 8 spaces wide. Live with it. It's the only sane solution. Actually, part of the mess with tabs is due to the fact they're not exactly 8 spaces wide, but any width that ends at a multiple of 8 characters from the start of the line. So 0 <= n < 8 spaces and a tab is still 8 spaces. Anyways, it's maybe just simpler to run indent before sending patches. Mike ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:36 ` Mike Hommey @ 2007-10-16 19:47 ` Linus Torvalds 2007-10-16 19:51 ` Linus Torvalds 2007-10-16 20:32 ` Matthieu Moy 0 siblings, 2 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-16 19:47 UTC (permalink / raw) To: Mike Hommey; +Cc: Jari Aalto, git On Tue, 16 Oct 2007, Mike Hommey wrote: > > Actually, part of the mess with tabs is due to the fact they're not > exactly 8 spaces wide, but any width that ends at a multiple of 8 > characters from the start of the line. So 0 <= n < 8 spaces and a tab > is still 8 spaces. Umm.. That's the definition of "tab width". The tab width is 8. Not "0 < n <= 8". Not "depends on where you are". The tab width is 8. The whole history of tab is that it comes from mechanical "tab stops" that you could set, and that were independent of the text - pressing the tab key would move to the next tab stop. Now, those tab stops were movable, and in fact, I think lots of terminals still support setting those tab stops dynamically (ie you can send control sequences to set their "tab stops" to different points, exactly like an old mechanical typewriter). But when it comes to computers, 8-character wide tab stops is the de-facto standard. It's what every single terminal defaults to. It's the only thing that some printers/terminals support. Anything else is by definition non-standard. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:47 ` Linus Torvalds @ 2007-10-16 19:51 ` Linus Torvalds 2007-10-16 20:32 ` Matthieu Moy 1 sibling, 0 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-16 19:51 UTC (permalink / raw) To: Mike Hommey; +Cc: Jari Aalto, git On Tue, 16 Oct 2007, Linus Torvalds wrote: > > But when it comes to computers, 8-character wide tab stops is the > de-facto standard. It's what every single terminal defaults to. It's the > only thing that some printers/terminals support. Anything else is by > definition non-standard. Side note: one reason you *have* to use 8-character wide tab stops if you want to be sane is that while your editor may have alternate tab-stops, but when you look at the sources any other ways or on any other setup, the default is *always* going to be that 8-character wide tab-stop. Do a "git cat-file -p :Makefile", and it will default to using "less". Have you added "-x2" to you LESS environment variable? Has everybody else? Not likely. Or what happens when you just cat it straight, without any less at all? In short: using anything but 8-char wide tab-stops is INSANE, because it will inevitably showing the same source code in different ways depending on which editor or other environment you use. In contrast, if you just accept that 8-wide tabs are a fact, you never see any of these issues. Everything "just works". Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:47 ` Linus Torvalds 2007-10-16 19:51 ` Linus Torvalds @ 2007-10-16 20:32 ` Matthieu Moy 1 sibling, 0 replies; 100+ messages in thread From: Matthieu Moy @ 2007-10-16 20:32 UTC (permalink / raw) To: Linus Torvalds; +Cc: Mike Hommey, Jari Aalto, git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Tue, 16 Oct 2007, Mike Hommey wrote: >> >> Actually, part of the mess with tabs is due to the fact they're not >> exactly 8 spaces wide, but any width that ends at a multiple of 8 >> characters from the start of the line. So 0 <= n < 8 spaces and a tab >> is still 8 spaces. > > Umm.. That's the definition of "tab width". > > The tab width is 8. Not "0 < n <= 8". Not "depends on where you are". The > tab width is 8. Read better before replying, and I'm sure you'll agree with Mike ... -- Matthieu ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:20 ` Linus Torvalds 2007-10-16 19:36 ` Mike Hommey @ 2007-10-16 20:18 ` Tom Tobin 2007-10-16 23:05 ` Linus Torvalds 2007-10-16 20:56 ` Sam Ravnborg ` (2 subsequent siblings) 4 siblings, 1 reply; 100+ messages in thread From: Tom Tobin @ 2007-10-16 20:18 UTC (permalink / raw) To: Linus Torvalds; +Cc: git On Tue, 2007-10-16 at 12:20 -0700, Linus Torvalds wrote: > The only sane solution is the one the kernel and git have always used: > tabs are 8 spaces wide, and anybody who disagrees can go screw themselves. > If you don't have 8-character tabs, you *will* get odd indentation. > > And no, the answer is not to say "don't use tabs at all" and replace them > by spaces. The answer is *also* not "tabs are just for initial code > indents", because not only will most sane editors never even show the > difference, it's simply not how people work. So such a rule about > invisible things doesn't work. [...] > The fact that some projects have encouraged bad coding style and *insane* > tab values is not a git problem. We should teach people to do *better*, > not become worse just because others have done idiotic things. I'm reading two different ideas here, and it seems like you're conflating the two — and, in the process, telling some pretty smart people (smarter than me, anyhow) to go fuck themselves. If a project uses tabs, your statement regarding 8-char-width tabs makes sense; you need some rule by which you can assume others are viewing the same thing you are. But you then dismiss out of hand the option of using all spaces; Python has been getting along perfectly well for quite some time by following this rule, and my experience with the language leads me to believe it's the wiser of the choices. Questions over tab width simply *go away*; you pick an indentation level (Python uses 4) and stick with it. I'm not arguing that git should switch to all spaces; projects tend to become set in their ways, and consistency can be valuable. I'm merely pointing out that all-spaces is a quite *sane* option, even if it's one git doesn't choose. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 20:18 ` Tom Tobin @ 2007-10-16 23:05 ` Linus Torvalds 2007-10-16 23:51 ` Christer Weinigel 2007-10-17 5:56 ` David Kastrup 0 siblings, 2 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-16 23:05 UTC (permalink / raw) To: Tom Tobin; +Cc: git On Tue, 16 Oct 2007, Tom Tobin wrote: > > But you then dismiss out of hand the option of using all spaces I do indeed. I don't think it's sensible. And I did think I already answered that issue by talking about how most editors don't even support it or show the difference between tabs and spaces. For example, the editor I use - microemacs - supports tabs just fine. It does auto-indentation etc. But it does it with hard-tabs by default, so now you have to have some editor-specific setup for that particular project if you ever want to do anything else. And that's really what it boils down to. Everybody support 8-character hardtabs (and usually by default). They may support other things *too*, but any time you move away from that standard behaviour, you'll most likely find something that doesn't support the alternatives. So yes, the answer really is: "git uses 8-character hard-tabs, live with it". Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 23:05 ` Linus Torvalds @ 2007-10-16 23:51 ` Christer Weinigel 2007-10-17 0:45 ` Linus Torvalds 2007-10-17 5:56 ` David Kastrup 1 sibling, 1 reply; 100+ messages in thread From: Christer Weinigel @ 2007-10-16 23:51 UTC (permalink / raw) To: Linus Torvalds; +Cc: Tom Tobin, git On Tue, 16 Oct 2007 16:05:34 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote: > I do indeed. I don't think it's sensible. And I did think I already > answered that issue by talking about how most editors don't even > support it or show the difference between tabs and spaces. > > For example, the editor I use - microemacs - supports tabs just fine. > It does auto-indentation etc. But it does it with hard-tabs by > default, so now you have to have some editor-specific setup for that > particular project if you ever want to do anything else. > > And that's really what it boils down to. Everybody support > 8-character hardtabs (and usually by default). They may support other > things *too*, but any time you move away from that standard > behaviour, you'll most likely find something that doesn't support the > alternatives. Unfortunately most editors are totally confused about the difference between tab size and indentation level. Visual Studio, probably the most commonly used development environment on Windows, by default uses TAB characters that are 4 spaces wide, and users are recommended not to change that because of that a lot of existing Windows source code and examples uses those settings. Two years ago, when I last looked at it, Eclipse, a very commonly used development environment, managed to confuse tabs and indentation and make it almost impossible to write Java or C code with a tab size of 8 with a different indentation level. The Eclipse 3 betas did see some improvement there, I think it got possible to do the right thing in Java at least, but the normal text editor and C editor lagged behind. But it was still a big mess and it was much too easy for someone to get a tab size which is not 8. Hopefully this has been fixed by now, but I wouldn't bet any significant amount of money on it. Nedit (which runs on Linux) has a very confusing settings dialog with terms such as "tab spacing", "emulated tabs". I guess emulated tabs means the indentation level, but guess how easy that is to mess up. gedit can control the tab width, but has no setting at all for configuring the indentation level. Guess what people do when they want a 4 space indentation level? Yes, right, change the tab size to 4. A a former colleague who used visual slickedit usually produced code with tab size 4. I think I've gotten the same crap from ultra edit 32 users. And so on... Mercifully, _all_ of these editors have a setting to use spaces instead of tabs, and telling people to turn on that setting is the absolutely easiest way of making things "just work". Yes, I know, the correct answer is to tell people to always use tab size 8, and I frequently and loudly do that. But at the same time, perfect is the enemy of good. It's much easier to explain "tabs will act differently in different editors, but if you always us spaces it will not be a problem" than to get into a discussion about the semantic difference between tab size and indentation. If you assume that everyone is sane and use a tab size of 8 you will get bitten, sooner or later. Or actually, you, Linus, who are lucky enough to work mostly with Linux source, you might personally not get bitten all that often. But us poor suckers that have to work with other people, often Windows programmers, we do. /Christer ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 23:51 ` Christer Weinigel @ 2007-10-17 0:45 ` Linus Torvalds 2007-10-17 3:08 ` Michael Witten 2007-10-17 7:17 ` Luke Lu 0 siblings, 2 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 0:45 UTC (permalink / raw) To: Christer Weinigel; +Cc: Tom Tobin, git On Wed, 17 Oct 2007, Christer Weinigel wrote: > > If you assume that everyone is sane and use a tab size of 8 you will > get bitten, sooner or later. Or actually, you, Linus, who are lucky > enough to work mostly with Linux source, you might personally not get > bitten all that often. But us poor suckers that have to work with > other people, often Windows programmers, we do. One issue may well be that Windows programmers also probably don't work very much with patches, do they? One reason for *really* wanting to use hard-tabs is that it makes patches look better, exactly because diffs contain that one extra (or two, in the case of old-style context diffs) character at the beginning of the line. Which means that while all-space indents look fine, *mixing* styles definitely does not. In particular, a two-character indent (which hopefully nobody uses, but people are crazy) will be totally unreadable as a patch if you have the (fairly common, at least in UNIX projects) style of using spaces for less-than-eight-character-indents and tabs for the full 8 characters. (In particular, a 3-level and 4-level indent will look *identical* in such a project, when using context diffs). And sure, you can use all-spaces-everywhere, but that just isn't what any normal UNIX editors are set up for by default. In contrast, under UNIX, I can pretty much guarantee that hard-tab indents look at least reasonable in any editor. And if you have an editor that shows hard-tabs as 4-character indents, generally you can work with it. You may have odd indentation, and people may complain about your patches not lining up, and yes, it would be up to *you* to understand that 8-wide tabs are the normal and default. But you can certainly work with a source base that uses a single hard-tab for indentation. In contrast, if you use spaces (or worse - mixing), things really look ugly as sin, to the point of actually being unworkable. In short: - if the project has the rule that an indentation is "one hard-tab", then at least everybody can *work* with that project. Different people may see things laid out slightly differently, but it's generally not a horrible disaster, especially if you aim to use block comments indented with the code (like we *mostly* do both in the kernel and in git) - all-space and all-tabs just leads to problems. Yes, I know about python, but lets face it, python is different, since the spacing has semantic rules there. Most non-python programmers will not use editors where you can obviously see the difference between spaces and tabs, and as a result an all-space model will *turn* into a mixed-space/tab model, and you get horrible end results. - as per above, mixing spaces and tabs is a *horrid* idea. - as a result, a "pure tab for indents" model tends to be workable in most situations. It may not be ideal for you, but it's workable. - and at least in the UNIX world, default for pure tabs really is 8 characters. Even if you have an editor that shows them as four, you'll see different results outside the editor (eg "grep -5 file.c"), so people should just consider other tab sizes to be "secondary". And as long as 99% of all git developers are under Linux, and all the core ones seem to have had no problem with the current tab rules, I really don't see why that should change. See? Hard-tabs are good. Maybe Windows people don't ever see patches (perhaps they only see them as side-by-side graphical things), and maybe windows projects are always done inside *one* environment where there is no "grep" and "terminal TAB size" and "fifty different editors with different defaults". But even in DOS/Windows, hard-tabs seem to be quite common, judging by what little source code I've seen from Windows projects. And I just checked. The current git model seems to work fine if you have an editor that thinks tabs are 4 spaces: sed 's/ / /g' < revision.c | less -S (that's a hard-tab in that first regex). No, things don't necessarily line up just like they should, but you actually have to *look* for problems to see them (ie stuff where people have added line-breaks). And is it really so unreasonable to just say "8-character tabs are the gold standard"? Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 0:45 ` Linus Torvalds @ 2007-10-17 3:08 ` Michael Witten 2007-10-17 3:29 ` Linus Torvalds 2007-10-17 7:17 ` Luke Lu 1 sibling, 1 reply; 100+ messages in thread From: Michael Witten @ 2007-10-17 3:08 UTC (permalink / raw) To: git; +Cc: Linus Torvalds On 16 Oct 2007, at 8:45:51 PM, Linus Torvalds wrote: > And is it really so unreasonable to just say "8-character tabs are the > gold standard"? It's unreasonable not to list that anywhere. mfwitten ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 3:08 ` Michael Witten @ 2007-10-17 3:29 ` Linus Torvalds 0 siblings, 0 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 3:29 UTC (permalink / raw) To: Michael Witten; +Cc: git On Tue, 16 Oct 2007, Michael Witten wrote: > > On 16 Oct 2007, at 8:45:51 PM, Linus Torvalds wrote: > > > And is it really so unreasonable to just say "8-character tabs are the > > gold standard"? > > It's unreasonable not to list that anywhere. Heh. I was sure we had a "CodingStyle", but it turns out that no, we don't, and yes, the 8-tab assumption is implicit in (a) the kernel rules (which git started out following for obvious reasons, and which *does* have documentation making this very explicit indeed) and (b) those few places where you can actually see it in the result. So maybe it should be made explicit. You can see the effect right now by doing git grep -1 ' ' *.c (again, that regex is a "tab+space", although it's not obvious) and then looking for places where we line up things in ways that simply wouldn't have worked if it wasn't a 8-wide tab, ie things like ... check_all_attr = xrealloc(check_all_attr, sizeof(*check_all_attr) * attr_nr); .. read_tree_recursive(args->tree, args->base, plen, 0, args->pathspec, write_zip_entry); .. where the arguments wouldn't line up for anything but 8-char-wide tabs. (But the code is certainly *readable* with other tab sizes, so it's not like this makes it impossible to work if somebody has a 4-space tab, it just means that such people can get odd effects - but they may not even realize that others see things line up!) Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 0:45 ` Linus Torvalds 2007-10-17 3:08 ` Michael Witten @ 2007-10-17 7:17 ` Luke Lu 2007-10-17 9:09 ` Michael Witten ` (2 more replies) 1 sibling, 3 replies; 100+ messages in thread From: Luke Lu @ 2007-10-17 7:17 UTC (permalink / raw) To: Linus Torvalds; +Cc: Christer Weinigel, Tom Tobin, git I'm late in this game. But it's too classic a debate to miss the fun. On Oct 16, 2007, at 5:45 PM, Linus Torvalds wrote: > One issue may well be that Windows programmers also probably don't > work > very much with patches, do they? > > One reason for *really* wanting to use hard-tabs is that it makes > patches > look better, exactly because diffs contain that one extra (or two, > in the > case of old-style context diffs) character at the beginning of the > line. > > Which means that while all-space indents look fine, *mixing* styles > definitely does not. In particular, a two-character indent (which > hopefully nobody uses, but people are crazy) will be totally > unreadable as > a patch if you have the (fairly common, at least in UNIX projects) > style > of using spaces for less-than-eight-character-indents and tabs for the > full 8 characters. Yes, all-space would look fine in patches. It'll look better than all tabs for tables and ascii formula and diagrams in comments, as one prepended character could screw up the tabs (depending on the content), rendering them totally unreadable. In all-space case, things just shift to the right by one character column. I believe the indentation convention for ruby is 2 spaces. It looks tight to me :) > (In particular, a 3-level and 4-level indent will look *identical* > in such > a project, when using context diffs). > > And sure, you can use all-spaces-everywhere, but that just isn't > what any > normal UNIX editors are set up for by default. In contrast, under > UNIX, I > can pretty much guarantee that hard-tab indents look at least > reasonable > in any editor. But all-space would look perfect in any editor as the authors intended, including the tables and ascii arts, as long as it's using monospace font. It's easy to setup all space editing on all platforms (Windows, Mac, *nix) It's also much easier to enforce. I've used pre- commit hook to check for tabs in the source and reject them if a tab is found :) > And if you have an editor that shows hard-tabs as 4-character indents, > generally you can work with it. You may have odd indentation, and > people > may complain about your patches not lining up, and yes, it would be > up to > *you* to understand that 8-wide tabs are the normal and default. > But you > can certainly work with a source base that uses a single hard-tab for > indentation. > In contrast, if you use spaces (or worse - mixing), things really look > ugly as sin, to the point of actually being unworkable. > Well, we just established that all-space is perfect, look-wise. > In short: > > - if the project has the rule that an indentation is "one hard- > tab", then > at least everybody can *work* with that project. Different > people may > see things laid out slightly differently, but it's generally not a > horrible disaster, especially if you aim to use block comments > indented > with the code (like we *mostly* do both in the kernel and in git) > > - all-space and all-tabs just leads to problems. Yes, I know about > python, but lets face it, python is different, since the spacing > has > semantic rules there. Most non-python programmers will not use > editors > where you can obviously see the difference between spaces and > tabs, and > as a result an all-space model will *turn* into a mixed-space/tab > model, and you get horrible end results. As I mentioned, an all-space policy is trivial to enforce. > - as per above, mixing spaces and tabs is a *horrid* idea. > > - as a result, a "pure tab for indents" model tends to be workable in > most situations. It may not be ideal for you, but it's workable. > > - and at least in the UNIX world, default for pure tabs really is 8 > characters. Even if you have an editor that shows them as four, > you'll > see different results outside the editor (eg "grep -5 file.c"), so > people should just consider other tab sizes to be "secondary". > > And as long as 99% of all git developers are under Linux, and > all the > core ones seem to have had no problem with the current tab rules, I > really don't see why that should change. > > See? Hard-tabs are good. Maybe Windows people don't ever see patches > (perhaps they only see them as side-by-side graphical things), and > maybe > windows projects are always done inside *one* environment where > there is > no "grep" and "terminal TAB size" and "fifty different editors with > different defaults". > > But even in DOS/Windows, hard-tabs seem to be quite common, judging by > what little source code I've seen from Windows projects. > > And I just checked. The current git model seems to work fine if you > have > an editor that thinks tabs are 4 spaces: > > sed 's/ / /g' < revision.c | less -S > > (that's a hard-tab in that first regex). No, things don't > necessarily line > up just like they should, but you actually have to *look* for > problems to > see them (ie stuff where people have added line-breaks). > > And is it really so unreasonable to just say "8-character tabs are the > gold standard"? But I still haven't seen any compelling arguments against the "all space" case, other than "people will screw it up into mixed spaces", which is really a straw man, as many multi-platform projects enforced the all-space policy easily by using a pre-commit hook in maintainers' repository. The only downside of all-space is a moderate space bloat in source, which is insignificant, all things considered. I agree that "8-character tabs are the gold standard", only for the tabstop==8 part but not the indent==tab part. For me the question is: is it really so unreasonable to just say "all-space is the holy grail"? __Luke ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 7:17 ` Luke Lu @ 2007-10-17 9:09 ` Michael Witten 2007-10-17 10:03 ` Luke Lu ` (2 more replies) 2007-10-17 15:53 ` Linus Torvalds 2007-10-17 16:08 ` David Kastrup 2 siblings, 3 replies; 100+ messages in thread From: Michael Witten @ 2007-10-17 9:09 UTC (permalink / raw) To: Luke Lu; +Cc: git On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: > But I still haven't seen any compelling arguments against the "all > space" case Overhead! If you use 8 spaces instead of one tab, that's using up 7x more space! Consider: # calculates the extra space required to # use the given number of spaces/tab. size() { count=`grep -RIo "\`printf \"\t\"\`" . | wc -l`; perl -e "print $count*$(($1-1))/1024/1024 . \" MB\n\""; } Then in in a git working tree: size 8; # 1.28701210021973 MB size 4; # 0.551576614379883 MB In a linux kernel working tree: size 8; # 61.4902725219727 MB size 4; # 26.3529739379883 MB Conclusion: Yikes! I hate tabs, but I can't argue with that! Michael Witten ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 9:09 ` Michael Witten @ 2007-10-17 10:03 ` Luke Lu 2007-10-17 10:21 ` Nikolai Weibull 2007-10-17 22:02 ` Jari Aalto 2 siblings, 0 replies; 100+ messages in thread From: Luke Lu @ 2007-10-17 10:03 UTC (permalink / raw) To: Michael Witten; +Cc: git On Oct 17, 2007, at 2:09 AM, Michael Witten wrote: > > On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: > >> But I still haven't seen any compelling arguments against the "all >> space" case > > Overhead! > > If you use 8 spaces instead of one tab, > that's using up 7x more space! > > Consider: > > # calculates the extra space required to > # use the given number of spaces/tab. > size() > { > count=`grep -RIo "\`printf \"\t\"\`" . | wc -l`; > perl -e "print $count*$(($1-1))/1024/1024 . \" MB\n\""; > } > > Then in in a git working tree: > > size 8; # 1.28701210021973 MB > size 4; # 0.551576614379883 MB First, the overhead is not a simple x4 or x8 conversion in size, but it's the upper bound. Given that, let's look at the percentage of the overhead: my git working tree is 56MB after gc, so the overhead is 2.3% max for size 8 and 0.98% for size 4. That's not significant at all. > > In a linux kernel working tree: > > size 8; # 61.4902725219727 MB > size 4; # 26.3529739379883 MB > > Conclusion: > > Yikes! Now, compile the kernel, do a du in the tree and report back percentages of the overhead. Disk is cheap (1GB costs less than half a dollar), people's productivity/time is not. The overhead argument is compelling, not! __Luke ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 9:09 ` Michael Witten 2007-10-17 10:03 ` Luke Lu @ 2007-10-17 10:21 ` Nikolai Weibull 2007-10-17 11:23 ` Michael Witten 2007-10-17 22:02 ` Jari Aalto 2 siblings, 1 reply; 100+ messages in thread From: Nikolai Weibull @ 2007-10-17 10:21 UTC (permalink / raw) To: Michael Witten; +Cc: Luke Lu, git On 10/17/07, Michael Witten <mfwitten@mit.edu> wrote: > > On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: > > > But I still haven't seen any compelling arguments against the "all > > space" case > > Overhead! > > If you use 8 spaces instead of one tab, > that's using up 7x more space! > > Consider: > > # calculates the extra space required to > # use the given number of spaces/tab. > size() > { > count=`grep -RIo "\`printf \"\t\"\`" . | wc -l`; > perl -e "print $count*$(($1-1))/1024/1024 . \" MB\n\""; > } > > Then in in a git working tree: > > size 8; # 1.28701210021973 MB > size 4; # 0.551576614379883 MB > > In a linux kernel working tree: > > size 8; # 61.4902725219727 MB > size 4; # 26.3529739379883 MB As already pointed out, this isn't the true waste. Run the following Ruby script to determine the true waste: ------------ cut here ----------- TabWidth = 8 actual_size = 0 expanded_size = 0 ARGF.each_line do |line| width = 0 line.each_byte do |byte| width += (byte == ?\t) ? (TabWidth - (width % TabWidth)) : 1 end actual_size += line.length expanded_size += width end puts (expanded_size - actual_size).to_s ------------ cut here ----------- This will give you the actual space waste. Run it like so: % ruby space-waste.rb /usr/src/linux/**/*.[ch] (or in a similar manner that doesn't fail due to going over the maximum command-line limit). According to this calculation the waste is 47808782 bytes, or about 45.6 MiB, for 8-spaces-wide tabs. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 10:21 ` Nikolai Weibull @ 2007-10-17 11:23 ` Michael Witten 0 siblings, 0 replies; 100+ messages in thread From: Michael Witten @ 2007-10-17 11:23 UTC (permalink / raw) To: Nikolai Weibull; +Cc: git On 17 Oct 2007, at 6:21:30 AM, Nikolai Weibull wrote: > According to this calculation the waste is 47808782 bytes, or about > 45.6 MiB, for 8-spaces-wide tabs. I concede my calculation was crude. Interestingly, modifying my calculation to look for tabs at the beginning of the line gives a similar result: # calculates the extra space required to # use the given number of spaces/tab. size() { count=`grep -RIo "^\`printf \"\t\"\`" . | wc -l`; perl -e "print $count*$(($1-1))/1024/1024 . \" MiB\n\""; } size 8; => 49.7416791915894 MiB and for git: size 8; => 1.25082969665527 MiB Anyway, thanks for the neat script. mfwitten ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 9:09 ` Michael Witten 2007-10-17 10:03 ` Luke Lu 2007-10-17 10:21 ` Nikolai Weibull @ 2007-10-17 22:02 ` Jari Aalto 2007-10-17 22:36 ` Andreas Ericsson 2007-10-18 5:42 ` Mike Hommey 2 siblings, 2 replies; 100+ messages in thread From: Jari Aalto @ 2007-10-17 22:02 UTC (permalink / raw) To: git * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu > On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: > >> But I still haven't seen any compelling arguments against the "all >> space" case > > Overhead! > > If you use 8 spaces instead of one tab, > that's using up 7x more space! Software is the right place to worry about optimization. We should trust SCM to make proper and efficient deltas. If not, algorithms need improvemnts. Any cross platform development or electronic exchange is guaranteed to be interpreted correctly when policy enforces "only spaces" As we have already seen in numerous times in this thread, using tabs will - eventually - be interpreted in some editor, in some display, in some encironment using some tools ... incorrectly or different than the author intended. Simply because editors are configurable and we cannot know what settings they may have when they load the file in. There is no such problem with spaces. The storage constraints are insignificant given the disk space vs. cost; including possibly used compression algorithms in storage or transfers. Jari -- Welcome to FOSS revolution: we fix and modify until it shines ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 22:02 ` Jari Aalto @ 2007-10-17 22:36 ` Andreas Ericsson 2007-10-17 23:38 ` Jari Aalto 2007-10-18 7:15 ` David Kågedal 2007-10-18 5:42 ` Mike Hommey 1 sibling, 2 replies; 100+ messages in thread From: Andreas Ericsson @ 2007-10-17 22:36 UTC (permalink / raw) To: Jari Aalto; +Cc: git Jari Aalto wrote: > * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU> > * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu >> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: >> >>> But I still haven't seen any compelling arguments against the "all >>> space" case >> Overhead! >> >> If you use 8 spaces instead of one tab, >> that's using up 7x more space! > > Software is the right place to worry about optimization. We should trust > SCM to make proper and efficient deltas. If not, algorithms need > improvemnts. > > Any cross platform development or electronic exchange is guaranteed to > be interpreted correctly when policy enforces "only spaces" > > As we have already seen in numerous times in this thread, using tabs > will - eventually - be interpreted in some editor, in some display, in > some encironment using some tools ... incorrectly or different than the > author intended. Simply because editors are configurable and we cannot > know what settings they may have when they load the file in. > And simply because nearly all (unix) editors still insert a hard tab when pressing the tab key, and *mixing* tabs and spaces makes the situation *really* unbearable, one really shouldn't use all spaces. It's code, not graphics. If it's really horrible, any editor can be configured to change the non-default tab-setting back to 8 if that's the problem. Mine's set to 4. Primarily because I think 8 is too much. Sometimes (roughly once every 2 years), that gives me problem. It's exclusively when someone has consciously mixed tabs and spaces. Using either or *never* gives any problem. > There is no such problem with spaces. > I beg to differ, for reasons stated multiple times elsewhere in this thread. > The storage constraints are insignificant given the disk space vs. cost; Perhaps, but it's low-hanging fruit and since all spaces have its issues too, why not just go with tabs? -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 22:36 ` Andreas Ericsson @ 2007-10-17 23:38 ` Jari Aalto 2007-10-18 4:31 ` Dmitry Torokhov 2007-10-18 7:15 ` David Kågedal 1 sibling, 1 reply; 100+ messages in thread From: Jari Aalto @ 2007-10-17 23:38 UTC (permalink / raw) To: git * Thu 2007-10-18 Andreas Ericsson <ae@op5.se> gmane.comp.version-control.git * Message-Id: 47168E70.4070305@op5.se > And simply because nearly all (unix) editors still insert a hard tab > when pressing the tab key, and *mixing* tabs and spaces makes the > situation *really* unbearable, one really shouldn't use all spaces. There was no assumption about a particular OS or editors. The QA tools will take care of warning or making automatic formatting before the code is put to SCM. In projects you cannot assume anything about people, their tools or what OS they might use at hand. >> There is no such problem with spaces. >> > > I beg to differ, for reasons stated multiple times elsewhere in this > thread. Consider: - Any editor will display the text written in "all spaces" 100 % the same. Regradless of any viewer or editor used. But the same is not true with text that uses tabs (because you really can't know what options the editor is preset / user set / regarding the treatment of tabs). The score is 1 - 0 for "all spaces" in this contest. -- Welcome to FOSS revolution: we fix and modify until it shines ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 23:38 ` Jari Aalto @ 2007-10-18 4:31 ` Dmitry Torokhov 2007-10-18 8:19 ` Jari Aalto 0 siblings, 1 reply; 100+ messages in thread From: Dmitry Torokhov @ 2007-10-18 4:31 UTC (permalink / raw) To: Jari Aalto; +Cc: git On Wednesday 17 October 2007, Jari Aalto wrote: > - Any editor will display the text written in "all spaces" > 100 % the same. Regradless of any viewer or editor used. > > But the same is not true with text that uses tabs (because you > really can't know what options the editor is preset / user set / > regarding the treatment of tabs). > > The score is 1 - 0 for "all spaces" in this contest. > How about this - I like tabs because when you removing it you need to hit Backspace just once and don't have to strain your eyes figuring out "Did I delete enough? Does it line up now?" -- Dmitry ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 4:31 ` Dmitry Torokhov @ 2007-10-18 8:19 ` Jari Aalto 2007-10-18 11:34 ` Petr Baudis 0 siblings, 1 reply; 100+ messages in thread From: Jari Aalto @ 2007-10-18 8:19 UTC (permalink / raw) To: git * Thu 2007-10-18 Dmitry Torokhov <dmitry.torokhov@gmail.com> * Message-Id: 200710180031.54819.dmitry.torokhov@gmail.com > On Wednesday 17 October 2007, Jari Aalto wrote: > >> - Any editor will display the text written in "all spaces" >> 100 % the same. Regradless of any viewer or editor used. >> >> But the same is not true with text that uses tabs (because you >> really can't know what options the editor is preset / user set / >> regarding the treatment of tabs). >> >> The score is 1 - 0 for "all spaces" in this contest. >> > > How about this - I like tabs because when you removing it you > need to hit Backspace just once and don't have to strain your > eyes figuring out "Did I delete enough? Does it line up now?" First I must say that you're right. From user's perspective some things are convenient and some things not so convenient; it depends: a) select an editor where these are no-issues b) use an editor that can be configured so that these are no-issues c) use the current editor and live by its limitations I do not speak for any particular project here, just from a general perspective[1]: A project policy QA enforces standards so that everybody can expect things to work the same way. The common denominator from view perspective (person A, B, C, D ... loads the text into a editor) is "all spaces". Similarly if code is post processed, all tools can expect that there are no surprises (it's all spaces, no combination of spaces and tabs). The effect of a project policy in general is to enforce standards that may not necessary match everybody's preferences[2]. Jari [1] 99 % of the projects do not use Kernel's 8-wide indentation convention. In all seriously taken editors, the TAB-key is configurable to move to specific positions; so called "tab stops". Therefore "hit TAB-key to insert tab character" does not usually apply in coding context. In coding, the TAB-key is used to control the indentation level, which is a measure defined in Project policy (coding style). [2] The tabs vs spaces issue is simular to those of: - Starting curly brace placement policy: at EOL, or at separate line - Identifier naming policy: camelCase vs. dash_names -- Welcome to FOSS revolution: we fix and modify until it shines ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 8:19 ` Jari Aalto @ 2007-10-18 11:34 ` Petr Baudis 2007-10-18 11:39 ` Nikolai Weibull 0 siblings, 1 reply; 100+ messages in thread From: Petr Baudis @ 2007-10-18 11:34 UTC (permalink / raw) To: Jari Aalto; +Cc: git On Thu, Oct 18, 2007 at 11:19:48AM +0300, Jari Aalto wrote: > [1] 99 % of the projects do not use Kernel's 8-wide indentation > convention. 99 % of the list participants sorely wish this thread would die already. Petr "Pasky" Baudis ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 11:34 ` Petr Baudis @ 2007-10-18 11:39 ` Nikolai Weibull 2007-10-22 3:39 ` Miles Bader 0 siblings, 1 reply; 100+ messages in thread From: Nikolai Weibull @ 2007-10-18 11:39 UTC (permalink / raw) To: Petr Baudis; +Cc: Jari Aalto, git On 10/18/07, Petr Baudis <pasky@suse.cz> wrote: > On Thu, Oct 18, 2007 at 11:19:48AM +0300, Jari Aalto wrote: > > [1] 99 % of the projects do not use Kernel's 8-wide indentation > > convention. > 99 % of the list participants sorely wish this thread would die already. To change the subject, let me point out that the percent symbol should be juxtaposed with the number, that is, write "99%", not "99 %", in English. ;-) ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 11:39 ` Nikolai Weibull @ 2007-10-22 3:39 ` Miles Bader 0 siblings, 0 replies; 100+ messages in thread From: Miles Bader @ 2007-10-22 3:39 UTC (permalink / raw) To: Nikolai Weibull; +Cc: Petr Baudis, Jari Aalto, git "Nikolai Weibull" <now@bitwi.se> writes: > To change the subject, let me point out that the percent symbol should > be juxtaposed with the number, that is, write "99%", not "99 %", in > English. Hmm, but what if one uses a tab? -miles -- My books focus on timeless truths. -- Donald Knuth ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 22:36 ` Andreas Ericsson 2007-10-17 23:38 ` Jari Aalto @ 2007-10-18 7:15 ` David Kågedal 1 sibling, 0 replies; 100+ messages in thread From: David Kågedal @ 2007-10-18 7:15 UTC (permalink / raw) To: git Andreas Ericsson <ae@op5.se> writes: > Jari Aalto wrote: >> * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU> >> * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu >>> On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: >>> >>>> But I still haven't seen any compelling arguments against the "all >>>> space" case >>> Overhead! >>> >>> If you use 8 spaces instead of one tab, >>> that's using up 7x more space! >> >> Software is the right place to worry about optimization. We should trust >> SCM to make proper and efficient deltas. If not, algorithms need >> improvemnts. >> >> Any cross platform development or electronic exchange is guaranteed to >> be interpreted correctly when policy enforces "only spaces" >> >> As we have already seen in numerous times in this thread, using tabs >> will - eventually - be interpreted in some editor, in some display, in >> some encironment using some tools ... incorrectly or different than the >> author intended. Simply because editors are configurable and we cannot >> know what settings they may have when they load the file in. >> > > And simply because nearly all (unix) editors still insert a hard tab > when pressing the tab key, and *mixing* tabs and spaces makes the > situation *really* unbearable, one really shouldn't use all spaces. I guess that means that you consider emacs to be an obscure or non-unix editor? When you press TAB while editing program code in emacs it doesn't insert a hard tab. It reindents the current line according to the indentation rules. The whitespace at the beginning of the line is filled with spaces and/or tabs, depending on the indent-tabs-mode setting. -- David Kågedal ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 22:02 ` Jari Aalto 2007-10-17 22:36 ` Andreas Ericsson @ 2007-10-18 5:42 ` Mike Hommey 2007-10-18 10:36 ` Jari Aalto 1 sibling, 1 reply; 100+ messages in thread From: Mike Hommey @ 2007-10-18 5:42 UTC (permalink / raw) To: Jari Aalto; +Cc: git On Thu, Oct 18, 2007 at 01:02:32AM +0300, Jari Aalto wrote: > * Wed 2007-10-17 Michael Witten <mfwitten@MIT.EDU> > * Message-Id: E29971BA-7306-4570-8383-26D0C9C0B814@mit.edu > > On 17 Oct 2007, at 3:17:08 AM, Luke Lu wrote: > > > >> But I still haven't seen any compelling arguments against the "all > >> space" case > > > > Overhead! > > > > If you use 8 spaces instead of one tab, > > that's using up 7x more space! > > Software is the right place to worry about optimization. We should trust > SCM to make proper and efficient deltas. If not, algorithms need > improvemnts. > > Any cross platform development or electronic exchange is guaranteed to > be interpreted correctly when policy enforces "only spaces" > > As we have already seen in numerous times in this thread, using tabs > will - eventually - be interpreted in some editor, in some display, in > some encironment using some tools ... incorrectly or different than the > author intended. Simply because editors are configurable and we cannot > know what settings they may have when they load the file in. > > There is no such problem with spaces. There is such problem with spaces. A lot of editors will just insert tabs to indent a new line when the previous you were typing begins with enough spaces, in which case you end up with spaces and tabs mixed all the way. It ends up being worse than all tabs. Mike ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 5:42 ` Mike Hommey @ 2007-10-18 10:36 ` Jari Aalto 0 siblings, 0 replies; 100+ messages in thread From: Jari Aalto @ 2007-10-18 10:36 UTC (permalink / raw) To: git * Thu 2007-10-18 Mike Hommey <mh@glandium.org> gmane.comp.version-control.git * Message-Id: 20071018054246.GA9423@glandium.org >> Any cross platform development or electronic exchange is guaranteed to >> be interpreted correctly when policy enforces "only spaces" > > There is such problem with spaces. A lot of editors will just insert > tabs to indent a new line when the previous you were typing begins with > enough spaces, in which case you end up with spaces and tabs mixed all > the way. It ends up being worse than all tabs. There is "all-spaces", but there is no "all-tabs" choice. The latter will always be mixture of "spaces and tabs". We have no control how the tabs mix with spaces or vice versa: there could even be "eight spaces" + proper tabs. Speaking generalities (not the git project): People can't be controlled, or their settings. Therefore there is a policy and QA tools to monitor the issues and make things canonical; whatever that is for the project. Jari -- Welcome to FOSS revolution: we fix and modify until it shines ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 7:17 ` Luke Lu 2007-10-17 9:09 ` Michael Witten @ 2007-10-17 15:53 ` Linus Torvalds 2007-10-17 18:05 ` Johannes Schindelin ` (2 more replies) 2007-10-17 16:08 ` David Kastrup 2 siblings, 3 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 15:53 UTC (permalink / raw) To: Luke Lu; +Cc: Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Luke Lu wrote: > > Well, we just established that all-space is perfect, look-wise. But we also established that an all-space model is not stable, because any unix developers will start adding tabs instead of spaces. > As I mentioned, an all-space policy is trivial to enforce. Hell no, it's not. More importantly, I can guarantee that certain developers will refuse to be part of such a project with such an idiotic design that eats disk-space for no gain, and makes it impossible for me to use my normal editor. > But I still haven't seen any compelling arguments against the "all space" > case, other than "people will screw it up into mixed spaces", which is really > a straw man, as many multi-platform projects enforced the all-space policy > easily by using a pre-commit hook in maintainers' repository. Hey, you start your own projct, and you can enforce whatever idiotic rules you want to. But in the meantime, all-tab indentations are equally good, and are the defacto rule. So *you* are the one who should show compelling arguments for changing, and so far you haven't shown any. Really: what is the problem with hardtabs? Absolutely none. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 15:53 ` Linus Torvalds @ 2007-10-17 18:05 ` Johannes Schindelin 2007-10-17 18:25 ` Tom Tobin 2007-10-18 0:32 ` Jeff King 2 siblings, 0 replies; 100+ messages in thread From: Johannes Schindelin @ 2007-10-17 18:05 UTC (permalink / raw) To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git Hi, On Wed, 17 Oct 2007, Linus Torvalds wrote: > On Wed, 17 Oct 2007, Luke Lu wrote: > > > As I mentioned, an all-space policy is trivial to enforce. > > Hell no, it's not. > > More importantly, I can guarantee that certain developers will refuse to > be part of such a project with such an idiotic design that eats > disk-space for no gain, and makes it impossible for me to use my normal > editor. Yes. Me, for one. But heck, _everyone_ is free to fork. That is one of the missions of git: "fork!". You can maintain you tab-less fork, until people flock to you, deciding to use your repo instead of Junio's, or Shawn's. If enough people decide, you will have more followers than the others. Ciao, Dscho ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 15:53 ` Linus Torvalds 2007-10-17 18:05 ` Johannes Schindelin @ 2007-10-17 18:25 ` Tom Tobin 2007-10-17 18:54 ` Linus Torvalds 2007-10-18 0:32 ` Jeff King 2 siblings, 1 reply; 100+ messages in thread From: Tom Tobin @ 2007-10-17 18:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: git On Wed, 2007-10-17 at 08:53 -0700, Linus Torvalds wrote: > > On Wed, 17 Oct 2007, Luke Lu wrote: > > > > Well, we just established that all-space is perfect, look-wise. > > But we also established that an all-space model is not stable, because any > unix developers will start adding tabs instead of spaces. Damn unix developers! They just can't be controlled! ... seriously now. You're trying on one hand to enforce a particular indentation rule (use tabs for indentations, assume tabs are 8 characters wide, use spaces for partial indentation) — which assumes unix developers *can* follow a project's rules for coding style — and yet you're arguing *against* all-spaces because unix developers *can't* follow rules. Or is "unix developers" code for "my sample size of one"? > > As I mentioned, an all-space policy is trivial to enforce. > > Hell no, it's not. > > More importantly, I can guarantee that certain developers will refuse to > be part of such a project with such an idiotic design that eats disk-space > for no gain, and makes it impossible for me to use my normal editor. Interesting how you waver between "certain developers" and "me". I'm convinced at this point that your argument comes down to "I can't use my favorite text editor with all-spaces, therefore all-spaces sucks". As for *disk space*? When we can measure cheap drives in sizable fractions of *terabytes*, this simply isn't a serious argument. > > But I still haven't seen any compelling arguments against the "all space" > > case, other than "people will screw it up into mixed spaces", which is really > > a straw man, as many multi-platform projects enforced the all-space policy > > easily by using a pre-commit hook in maintainers' repository. > > Hey, you start your own projct, and you can enforce whatever idiotic rules > you want to. Yeah, can you believe some projects actually *survive* with an all-spaces indentation rule? And ::gasp:: even *thrive*? > But in the meantime, all-tab indentations are equally good, and are the > defacto rule. So *you* are the one who should show compelling arguments > for changing, and so far you haven't shown any. > > Really: what is the problem with hardtabs? Absolutely none. Problems have been outlined, but since everything for you comes down to "anything that comes between me and microemacs sucks", rational discussion breaks down. Thank goodness the git community (not to mention the Linux community!) is larger than you; they exist in no small part due to your programming skill and initial open-sourcing, but certainly in *spite* of your personality otherwise. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 18:25 ` Tom Tobin @ 2007-10-17 18:54 ` Linus Torvalds 2007-10-17 19:33 ` Tom Tobin 2007-10-17 19:47 ` Jan Wielemaker 0 siblings, 2 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 18:54 UTC (permalink / raw) To: Tom Tobin; +Cc: git On Wed, 17 Oct 2007, Tom Tobin wrote: > > Or is "unix developers" code for "my sample size of one"? Well, let's put it this way: that "sample" is the one that started the project. I got to pick the license. Are you going to argue about that too? I got to pick the way I wrote the code. Are you going to continue arguing about that? The fact is, I don't see the people arguing for spaces having actually *done* anything for git. So why are you arguing? > Interesting how you waver between "certain developers" and "me". I'm > convinced at this point that your argument comes down to "I can't use my > favorite text editor with all-spaces, therefore all-spaces sucks". Umm. And I've *told* you that. The whole point is: - every single damn editor out there can handle tabs. - it's the default - end of story. What's so hard to understand? > As for *disk space*? When we can measure cheap drives in sizable > fractions of *terabytes*, this simply isn't a serious argument. That disk-space translates into memory usage too, and into just being technically the *inferior* choice. How hard is that to accept? If you have a choice between a technically better solution, and a technically worse one, why are you arguing for the worse one? > Yeah, can you believe some projects actually *survive* with an > all-spaces indentation rule? And ::gasp:: even *thrive*? Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that *git* should not, the same way the Linux kernel does not and will not. Why? Because tabs are better. You (or anybody else) have simply never given any argument against that very simple argument. You try to push an inferior solution. > Problems have been outlined, but since everything for you comes down to > "anything that comes between me and microemacs sucks", rational > discussion breaks down. Don't talk about "rational discussion", since you don't even *have* any. The starting point for any rational decision would be to explain why changing tabs to spaces would actually improve anything at all. And you have yet to show *any* such argument, while I've shown arguments to the reverse. One big one being: the person who started the project and still actually *does* something for it actually cares. In contrast, your argument seems to be "I've not actually done anything, but I want to paint the bikeshed pink". Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 18:54 ` Linus Torvalds @ 2007-10-17 19:33 ` Tom Tobin 2007-10-17 19:44 ` Linus Torvalds ` (5 more replies) 2007-10-17 19:47 ` Jan Wielemaker 1 sibling, 6 replies; 100+ messages in thread From: Tom Tobin @ 2007-10-17 19:33 UTC (permalink / raw) To: Linus Torvalds; +Cc: git On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote: > > On Wed, 17 Oct 2007, Tom Tobin wrote: > > > > Or is "unix developers" code for "my sample size of one"? > > Well, let's put it this way: that "sample" is the one that started the > project. And therefore your choices become magically reasonable? > I got to pick the license. Are you going to argue about that too? I got to > pick the way I wrote the code. Are you going to continue arguing about > that? The way you *wrote* the code is different from deciding how the code *should* be written — or is your code set in stone? (Funny, considering that we're talking about a revision control system here.) As for the license bit — yes, you certainly *did* get to pick the license. What's your point? We wouldn't even be having this discussion if it wasn't open source. > The fact is, I don't see the people arguing for spaces having actually > *done* anything for git. So why are you arguing? Oh, here you pull out the big stick: if you haven't already done anything for git, your ideas (as for what to, hmm, do for git) are worthless! Err, yeah, great perspective there. > > Interesting how you waver between "certain developers" and "me". I'm > > convinced at this point that your argument comes down to "I can't use my > > favorite text editor with all-spaces, therefore all-spaces sucks". > > Umm. And I've *told* you that. > > The whole point is: > - every single damn editor out there can handle tabs. > - it's the default > - end of story. > > What's so hard to understand? Every single damn editor out there can handle spaces. The "default" is project-by-project. Since you're BD in git-land, yes, your say-so is ultimately end-of-story. It doesn't make your argument reasonable. > > As for *disk space*? When we can measure cheap drives in sizable > > fractions of *terabytes*, this simply isn't a serious argument. > > That disk-space translates into memory usage too, and into just being > technically the *inferior* choice. > > How hard is that to accept? If you have a choice between a technically > better solution, and a technically worse one, why are you arguing for the > worse one? That disk space translates into memory usage exactly *how*? Compiled code? Or the in-memory text while you're editing? The former can't be the issue, and the latter is trivial. And, of course, this still comes up against the *benefits* of all-spaces. Benefits which have been mentioned by several people; benefits which you refuse to *acknowledge*, even if they don't sway you. > > Yeah, can you believe some projects actually *survive* with an > > all-spaces indentation rule? And ::gasp:: even *thrive*? > > Hey, Ḯ'm not saying that others shouldn't use spaces. I'm saying that > *git* should not, the same way the Linux kernel does not and will not. > > Why? Because tabs are better. You (or anybody else) have simply never > given any argument against that very simple argument. You try to push an > inferior solution. Uh huh. > > Problems have been outlined, but since everything for you comes down to > > "anything that comes between me and microemacs sucks", rational > > discussion breaks down. > > Don't talk about "rational discussion", since you don't even *have* any. > > The starting point for any rational decision would be to explain why > changing tabs to spaces would actually improve anything at all. And you > have yet to show *any* such argument, while I've shown arguments to the > reverse. You're being willfully blind here. > One big one being: the person who started the project and still actually > *does* something for it actually cares. Because, once again, this makes your arguments correct, doesn't it? > In contrast, your argument seems to be "I've not actually done anything, > but I want to paint the bikeshed pink". Because, once again, being new makes one incorrect, doesn't it? You've essentially demonstrated that git's "benevolent" dictator is an asshole, and even worse, an irrational asshole. It's one thing to deal with a community member like that; when it's the BD, I think I'll move along elsewhere. Congratulations. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:33 ` Tom Tobin @ 2007-10-17 19:44 ` Linus Torvalds 2007-10-17 19:48 ` Nicolas Pitre ` (4 subsequent siblings) 5 siblings, 0 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 19:44 UTC (permalink / raw) To: Tom Tobin; +Cc: git On Wed, 17 Oct 2007, Tom Tobin wrote: > > > > Well, let's put it this way: that "sample" is the one that started the > > project. > > And therefore your choices become magically reasonable? They sure as hell automatically become a lot more relevant than YOUR choices, don't they? > Every single damn editor out there can handle spaces. Yes, and they'll start mixing spaces and tabs when they auto-indent. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:33 ` Tom Tobin 2007-10-17 19:44 ` Linus Torvalds @ 2007-10-17 19:48 ` Nicolas Pitre 2007-10-17 19:52 ` Josh England ` (3 subsequent siblings) 5 siblings, 0 replies; 100+ messages in thread From: Nicolas Pitre @ 2007-10-17 19:48 UTC (permalink / raw) To: Tom Tobin; +Cc: Linus Torvalds, git On Wed, 17 Oct 2007, Tom Tobin wrote: > On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote: > > In contrast, your argument seems to be "I've not actually done anything, > > but I want to paint the bikeshed pink". > > Because, once again, being new makes one incorrect, doesn't it? > > You've essentially demonstrated that git's "benevolent" dictator is an > asshole, and even worse, an irrational asshole. It's one thing to deal > with a community member like that; when it's the BD, I think I'll move > along elsewhere. Congratulations. If you can't overcome your dislike for tabs and accept that this is the coding style for the Git project then please go away. Can this discussion, rational or not, just stop now? Nicolas ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:33 ` Tom Tobin 2007-10-17 19:44 ` Linus Torvalds 2007-10-17 19:48 ` Nicolas Pitre @ 2007-10-17 19:52 ` Josh England 2007-10-17 19:53 ` Linus Torvalds ` (2 subsequent siblings) 5 siblings, 0 replies; 100+ messages in thread From: Josh England @ 2007-10-17 19:52 UTC (permalink / raw) To: Tom Tobin; +Cc: Linus Torvalds, git On Wed, 2007-10-17 at 14:33 -0500, Tom Tobin wrote: > That disk space translates into memory usage exactly *how*? Compiled > code? Or the in-memory text while you're editing? The former can't be > the issue, and the latter is trivial. Think compression. Worse yet in my opinion is the bandwidth spike that the larger tarball would create. Estimates earlier in the thread put the difference at upwards of 40MB. Disk space may be cheap, but highly available redundant mirrored disk space is not, and neither is bandwidth. > And, of course, this still comes up against the *benefits* of > all-spaces. Benefits which have been mentioned by several people; > benefits which you refuse to *acknowledge*, even if they don't sway you. I think what Linus is trying to say here is this: THE "BENEFITS" DO *NOT* OUTWEIGH THE DRAWBACKS. Accept it and move on. > You've essentially demonstrated that git's "benevolent" dictator is an > asshole, and even worse, an irrational asshole. It's one thing to deal > with a community member like that; when it's the BD, I think I'll move > along elsewhere. Congratulations. Lovely. Personal attacks are such an effective way to get your point across. You, sir, are a tool. Good riddance. -JE ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:33 ` Tom Tobin ` (2 preceding siblings ...) 2007-10-17 19:52 ` Josh England @ 2007-10-17 19:53 ` Linus Torvalds 2007-10-17 21:21 ` Christer Weinigel 2007-10-17 20:31 ` David Kastrup 2007-10-17 21:08 ` Johannes Schindelin 5 siblings, 1 reply; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 19:53 UTC (permalink / raw) To: Tom Tobin; +Cc: git On Wed, 17 Oct 2007, Tom Tobin wrote: > > And, of course, this still comes up against the *benefits* of > all-spaces. Benefits which have been mentioned by several people; > benefits which you refuse to *acknowledge*, even if they don't sway you. I notice how you didn't even list them. Why? Because they don't exist? So here's the deal: I claim that "use hard-tabs, and accept that they are 8 characters wide" is a provably working situation. For lots of *large* projects. I'm not some odd-ball person here, I bet that if you go and look at any sourceforge entry that is written in C (which is the language we're debating here), you'll find that the ones that use hard-tabs (even if they use spaces for smaller indents) are the vast majority. So what's your point? You're pushing something that is provably odd-ball, since almost nobody uses it, and you cannot even state what the huge advantages are, and you claim that I'm the one that ignores them, when it is *you* who have refused to acknowledge that there are reasons to *not* do it (one big reason being that there are current existing and productive developers that definitely do *not* want to change - and no, it wasn't just me, either). Your arguments make no sense. So *of*course* they don't sway me. And you know what? I don't much care if you aren't swayed by mine. It's to some degree a matter of taste, and the fact is, if you don't like the current git model, you can go away and play with your own model. It *is* open source, after all. Put another way: if you cannot respect the wishes of the people who have done the work, then I damn well have no reason what-so-ever to respect *yours*. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:53 ` Linus Torvalds @ 2007-10-17 21:21 ` Christer Weinigel 2007-10-17 22:03 ` Linus Torvalds 2007-10-17 22:11 ` Johannes Schindelin 0 siblings, 2 replies; 100+ messages in thread From: Christer Weinigel @ 2007-10-17 21:21 UTC (permalink / raw) To: Linus Torvalds; +Cc: Tom Tobin, git This is bloody ridiculous, but... On Wed, 17 Oct 2007 12:53:58 -0700 (PDT) Linus Torvalds <torvalds@linux-foundation.org> wrote: > So what's your point? You're pushing something that is provably > odd-ball, since almost nobody uses it, and you cannot even state what > the huge advantages are, and you claim that I'm the one that ignores > them, when it is *you* who have refused to acknowledge that there are > reasons to *not* do it (one big reason being that there are current > existing and productive developers that definitely do *not* want to > change - and no, it wasn't just me, either). > > And you know what? I don't much care if you aren't swayed by mine. > It's to some degree a matter of taste, and the fact is, if you don't > like the current git model, you can go away and play with your own > model. It *is* open source, after all. > > Put another way: if you cannot respect the wishes of the people who > have done the work, then I damn well have no reason what-so-ever to > respect *yours*. I think you would get at lot less argument if you weren't so damn self righteous about it. If you'd just said "it's a matter of taste and hard tabs 8 spaces wide are the way we prefer to do it and that's the way we want to keep doing it" I'd not have any problem with it. But when you start claiming that there are no reasons to use all spaces, and that it doesn't solve any problems (it definitely does), and that all editors work with hard tabs at 8 (which they don't), at least I get a bit frustrated with you. It's very non-respectful of you to claim that everyone is stupid that doesn't agree with you and is just asking for silly arguments. Yes, I know, you're an opinionated bastard and proud of it, but maybe you should tone that down a bit. (At least I got quite insulted by your Git talk at Google. People are not stupid just because they don't agree with you, most of the time they just have different preferences or different goals.) /Christer (trying to escape from Lilliput) ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 21:21 ` Christer Weinigel @ 2007-10-17 22:03 ` Linus Torvalds 2007-10-18 6:25 ` David Kastrup 2007-10-17 22:11 ` Johannes Schindelin 1 sibling, 1 reply; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 22:03 UTC (permalink / raw) To: Christer Weinigel; +Cc: Tom Tobin, git On Wed, 17 Oct 2007, Christer Weinigel wrote: > > But when you start claiming that there are no reasons to use all > spaces, and that it doesn't solve any problems (it definitely does), > and that all editors work with hard tabs at 8 (which they don't), at > least I get a bit frustrated with you. It's very non-respectful of you > to claim that everyone is stupid that doesn't agree with you and is > just asking for silly arguments. Yes, I know, you're an opinionated > bastard and proud of it, but maybe you should tone that down a bit. Hey, fair enough. I'm not very tolerant of people who haven't actually done anything, and then come in and say things should be done certain ways. The fact is, code talks, bullshit walks. And bullshit should most definitely not be encouraged. People like that should be discouraged *immediately*. I'm not interested in bikeshed painters, I think they should be told so forcefully enough that they either shut up or go away. Maybe it's a character flaw. I'll respect people who do something interesting, but re-implementing CVS (and badly, at that) or talking about syntactic changes to other peoples projects is not going to fill me with respect. In short, I'll give respect when somebody is shown to be *worth* that respect. But respect really has to be earned, not just "assumed", otherwise it's pointless. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 22:03 ` Linus Torvalds @ 2007-10-18 6:25 ` David Kastrup 0 siblings, 0 replies; 100+ messages in thread From: David Kastrup @ 2007-10-18 6:25 UTC (permalink / raw) To: Linus Torvalds; +Cc: Christer Weinigel, Tom Tobin, git Linus Torvalds <torvalds@linux-foundation.org> writes: > Maybe it's a character flaw. I'll respect people who do something > interesting, but re-implementing CVS (and badly, at that) I seem to remember somebody who started out reimplementing Unix, and badly, at that. With the help of many other people, this thing finally became portable to more than i386 and more than AT drives. Took quite a long time. The ancient floppy disk code still has the renown of being one of the worst pieces of drivers all around. If you find this silly, so do I. That's the point. > or talking about syntactic changes to other peoples projects is not > going to fill me with respect. > > In short, I'll give respect when somebody is shown to be *worth* > that respect. But respect really has to be earned, not just > "assumed", otherwise it's pointless. Cooperation is easier if one is of the opinion rather that disrespect has to be earned: otherwise you alienate potential contributors before they even had a chance to contribute. This difference in approach is one of the things I can't help admiring in Junio. And I don't think it is to the detriment of git. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 21:21 ` Christer Weinigel 2007-10-17 22:03 ` Linus Torvalds @ 2007-10-17 22:11 ` Johannes Schindelin 2007-10-17 23:17 ` Christer Weinigel 1 sibling, 1 reply; 100+ messages in thread From: Johannes Schindelin @ 2007-10-17 22:11 UTC (permalink / raw) To: Christer Weinigel; +Cc: Linus Torvalds, Tom Tobin, git Hi, On Wed, 17 Oct 2007, Christer Weinigel wrote: > I think you would get at lot less argument if you weren't so damn self > righteous about it. Why is it that in this thread, people whom I have heard _nothing_ of before seem to think this would be a good time to let their opinion be heard? Now, _that_ is what I call righteous. Show nothing but opinion. Ciao, Dscho ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 22:11 ` Johannes Schindelin @ 2007-10-17 23:17 ` Christer Weinigel 2007-10-17 23:44 ` Johannes Schindelin 2007-10-17 23:53 ` Linus Torvalds 0 siblings, 2 replies; 100+ messages in thread From: Christer Weinigel @ 2007-10-17 23:17 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Linus Torvalds, Tom Tobin, git On Wed, 17 Oct 2007 23:11:37 +0100 (BST) Johannes Schindelin <Johannes.w@gmx.de> wrote: > Hi, > > On Wed, 17 Oct 2007, Christer Weinigel wrote: > > > I think you would get at lot less argument if you weren't so damn > > self righteous about it. > > Why is it that in this thread, people whom I have heard _nothing_ of > before seem to think this would be a good time to let their opinion > be heard? Now, _that_ is what I call righteous. Show nothing but > opinion. I'm not that invisible am I? cd linux-2.6.22.7 find . -type f | xargs egrep -il "weinigel" | wc -l 17 Ahh, confirmation, I really do exist. The earliest LSM entry I can find for myself is from 1995: http://www.ibiblio.org/pub/linux/kernel/patches/scanners/hpscan-0.1.1.5.lsm Mmm, nostalgia. :-) But yes, I haven't contributed anything to git so far, I mostly lurk on the mailing list and try to keep up with what's happening to git. In the beginning I sent a few ideas to the list (which quite sadly were ignored), but unfortunately I've been busy with paying work to do much with git after that. And at work we use Perforce (yuk) or Subversion (a lot nicer than Perforce) and privately I use CVS just because I started using CVS ten years ago and haven't bothered to change. And when I'm free I prefer to hack on hardware or device drivers instead. The reason I wrote my first mail in this thread is that I work in a different environment than Linus does and wanted to share that experience. I usually work with embedded programming, where people use lots of different editors and in mixed environments. Some people use Visual Studio on Windows because that's what they use for host programming, a lot of embedded development is done in the (almost invariably sucky) IDE that comes with the compilers for the embedded CPU, such as Microchips MPLAB or IAR Workbench, Eclipse is becoming quite popular for C development, Slickedit is also popular on Windows, a colleague prefers nedit for some strange reason, and so on. In such a heterogeneous environment the easiest way to make sure that people see the same indentation in all editors is to just tell them to use spaces for indentation, and I think that every editor I just mentioned has a setting to do that automatically. Microemacs is the odd one out in that it doesn't support it. And my employers haven't really been paying me to go on a crusade for the holy TAB is 8 spaces cause, they just want things done, so I've had to settle for a "good enough" solution which works most of the time. So I just thought it was unfair of Linus to say that "use spaces" doesn't solve any problems, in some environments it does. For the Linux kernel and Git, it's easier for the maintainer to enforce the coding standards and since Linus and Junio prefer to use hard tabs, that are the rules that people who want to play with their toys have to adhere to. BTW, how serious is the problem with deltifying when there are a lot of spaces that David Kastrup mentioned? It does sound like a quite serious problem if it has a big impact on the performance of Git. Git isn't only used for the Linux kernel, so there has to be some projects that both use spaces for indentation and use Git out there. Wouldn't it be a problem when people put ASCII graphics in comments or just have comments like /*********************************/ in their code? /Christer ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 23:17 ` Christer Weinigel @ 2007-10-17 23:44 ` Johannes Schindelin 2007-10-18 0:31 ` Christer Weinigel 2007-10-17 23:53 ` Linus Torvalds 1 sibling, 1 reply; 100+ messages in thread From: Johannes Schindelin @ 2007-10-17 23:44 UTC (permalink / raw) To: Christer Weinigel; +Cc: Linus Torvalds, Tom Tobin, git Hi, On Thu, 18 Oct 2007, Christer Weinigel wrote: > On Wed, 17 Oct 2007 23:11:37 +0100 (BST) > Johannes Schindelin <Johannes.w@gmx.de> wrote: > > > On Wed, 17 Oct 2007, Christer Weinigel wrote: > > > > > I think you would get at lot less argument if you weren't so damn > > > self righteous about it. > > > > Why is it that in this thread, people whom I have heard _nothing_ of > > before seem to think this would be a good time to let their opinion > > be heard? Now, _that_ is what I call righteous. Show nothing but > > opinion. > > I'm not that invisible am I? > > cd linux-2.6.22.7 > find . -type f | xargs egrep -il "weinigel" | wc -l > 17 File or directory not found. We are not Linux specific here. Besides, I was talking about _git_ source code, just in case I did not make myself clear. > [...] and privately I use CVS just because I started using CVS ten years > ago and haven't bothered to change. I wonder why you have to leave your hideout and comment on the source code of _git_, then. I mean, why do _you_ care? (It should have become apparent to you that _we_ care, so it looks even more like you wanted to dictate a policy on git, which you have no business with.) Puzzled, and a little unnerved, Dscho ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 23:44 ` Johannes Schindelin @ 2007-10-18 0:31 ` Christer Weinigel 2007-10-18 6:02 ` Andreas Ericsson 2007-10-18 7:12 ` David Kågedal 0 siblings, 2 replies; 100+ messages in thread From: Christer Weinigel @ 2007-10-18 0:31 UTC (permalink / raw) To: Johannes Schindelin; +Cc: Linus Torvalds, Tom Tobin, git On Thu, 18 Oct 2007 00:44:22 +0100 (BST) Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote: > Hi, > > On Thu, 18 Oct 2007, Christer Weinigel wrote: > > > I'm not that invisible am I? > > > > cd linux-2.6.22.7 > > find . -type f | xargs egrep -il "weinigel" | wc -l > > 17 > > File or directory not found. > > We are not Linux specific here. Besides, I was talking about _git_ > source code, just in case I did not make myself clear. You do not have a sense of humor, do you? And you elided the paragraph where I said that I haven't contributed anything to git so far. :-/ > > [...] and privately I use CVS just because I started using CVS ten > > years ago and haven't bothered to change. > > I wonder why you have to leave your hideout and comment on the source > code of _git_, then. I mean, why do _you_ care? (It should have > become apparent to you that _we_ care, so it looks even more like you > wanted to dictate a policy on git, which you have no business with.) Where did I say that I'm not interested in git? If I weren't I wouldn't have been reading this mailing list since it was first created. The reason I don't use git is a lack of time. Professionally I usually have no need to use git since my employer doesn't use it. On my own time, I haven't even had time and energy to switch away from CVS, even though I ought to have done that years ago. I dabble a bit with git, mercurial, org bitkeeper (or did at least) when I need to access something out on the net which is stored in such a repository, but I haven't switched any of my projects over to using anything else. I'm definitely interested in git, and it's interesting to read the mailing list to see where git is going. And I'd definitely like git to move in a direction where it's usable for me, or even better, where I can recommend it to my (often Windows-only) colleagues. And once again you cut out the part where I said that git is Junio's baby, he decides what goes into the main git tree, and if he says 8 wide hard tabs, that it is. I haven't argued against that at all. So I'm wondering why you are trying to project things I haven't said on me. /Christer (pissing contensts are silly, so why the hell am I getting involved in one?) ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 0:31 ` Christer Weinigel @ 2007-10-18 6:02 ` Andreas Ericsson 2007-10-18 7:12 ` David Kågedal 1 sibling, 0 replies; 100+ messages in thread From: Andreas Ericsson @ 2007-10-18 6:02 UTC (permalink / raw) To: Christer Weinigel; +Cc: Johannes Schindelin, Linus Torvalds, Tom Tobin, git Christer Weinigel wrote: > > /Christer (pissing contensts are silly, so why the hell am I getting > involved in one?) Because the right to an opinion is so fundamental to us that when someone claims yours is stupid for reasons you (or me, or anyone) find unfair, we stand up and say so. It's not a sign of being stupid. It's a sign of being protective about a very basic democratic right, and oss people are usually very protective about those. Freedom of everything comes easier to people than "force christianity on the world, but keep your sources open!". Linus is definitely not the most polite of people out there. Had he been less than top-ranked in the meritocracy he would have been utterly and totally annihilated on several mailing lists a really long time ago. At the same time, he's entitled to his opinion the same way everyone is, and he's entitled to express it any way he wants. When he's *really* off the mark, people will tell him so. Or ignore him totally, like an embarrassing grandfather who's just gotten too drunk at the christmas dinner and started fondling his grandsons girlfriend. However, the same goes for everyone else, and Linus *is* fond of telling people "so". If nothing else, it saves time to head off dead ends right at the start. Linus isn't sacrosankt, just enough of a corner-stone that people will keep listening to him even if he's wildly offending. tabs-vs-spaces is not, I feel, a discussion that has a great impact in the world, so being "really off the mark" is not really possible there. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 0:31 ` Christer Weinigel 2007-10-18 6:02 ` Andreas Ericsson @ 2007-10-18 7:12 ` David Kågedal 1 sibling, 0 replies; 100+ messages in thread From: David Kågedal @ 2007-10-18 7:12 UTC (permalink / raw) To: git Christer Weinigel <christer@weinigel.se> writes: > I usually have no need to use git since my employer doesn't use it. That is actually not true. My employer doesn't use it either (we use svn). But that doesn't stop me from using it all the time. git is an excellent offline svn client. (hej wingel) -- David Kågedal ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 23:17 ` Christer Weinigel 2007-10-17 23:44 ` Johannes Schindelin @ 2007-10-17 23:53 ` Linus Torvalds 1 sibling, 0 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-17 23:53 UTC (permalink / raw) To: Christer Weinigel; +Cc: Johannes Schindelin, Tom Tobin, git On Thu, 18 Oct 2007, Christer Weinigel wrote: > > BTW, how serious is the problem with deltifying when there are a lot of > spaces that David Kastrup mentioned? I suspect it works quite well in practice. But we've had to tweak the xdiff code before, and the hash calculations for bucket size limits. If somebody actually points out a problem case, we can probably tweak it again. > Wouldn't it be a problem when people put ASCII graphics in comments or > just have comments like /*********************************/ in their > code? In general, *any* situation where you have tons of character sequences that are the same (and here it's not the characters *themselves* that have to be the same - it's the *sequence* that has to be the same, so it's not about repeating the same character over and over per se: it's about repeating a certain block of characters many many times in the source code) will be problematic for pretty much any similarity analysis. Why? Because you just have a lot of the same sequence, and to get a good delta you want to find common "sequences of these sequences" (call them supersequences) in order to find the biggest common chunk. So the badly performing cases for any delta algorithm (and I do want to point out that this has nothing what-so-ever to do with the particular one that git uses) tends to be exactly the ones where you have lots and lots of smaller chunks that match in two files, and that then makes it costlier to find the *bigger* chunks that are build up of those smaller chunks. And generally you tend to have two situations: you either (a) take *much* longer to find the common areas (they are often quadratic or worse algorithms) or (b) you decide to ignore chunks that are so common that they don't really add any real information when it comes to finding truly common chunks. Where that second choice generally means that you can miss some cases where you *could* have found a good match for deltification. In fact, usually you have a combination of the above two effects: certain deltas may be more expensive to find but there is also a limit that kicks in and means that you never spend *too* much time on finding them if the pattern space is not amenable to it. Would lots of spaces be such a pattern? I personally doubt it would really matter. In general, source code is easy to delta: the bulk of any common sequences in most files will be found by the trivial "look for common sequences in the beginning and the end". The really *bad* cases tend to be rather odd, and often generated files. So no, I don't think deltification is a huge deal for spaces. But it does boil down to the same kind of issues: if you blow up the source base by 20%, you often slow down things by 20% or more, simply because there is more data to process at all stages. It simply just slows down everything - totally unnecessarily. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:33 ` Tom Tobin ` (3 preceding siblings ...) 2007-10-17 19:53 ` Linus Torvalds @ 2007-10-17 20:31 ` David Kastrup 2007-10-17 21:08 ` Johannes Schindelin 5 siblings, 0 replies; 100+ messages in thread From: David Kastrup @ 2007-10-17 20:31 UTC (permalink / raw) To: Tom Tobin; +Cc: Linus Torvalds, git Tom Tobin <korpios@korpios.com> writes: > On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote: > >> In contrast, your argument seems to be "I've not actually done >> anything, but I want to paint the bikeshed pink". > > Because, once again, being new makes one incorrect, doesn't it? > > You've essentially demonstrated that git's "benevolent" dictator is > an asshole, and even worse, an irrational asshole. You are doing Junio a harsh injustice here. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 19:33 ` Tom Tobin ` (4 preceding siblings ...) 2007-10-17 20:31 ` David Kastrup @ 2007-10-17 21:08 ` Johannes Schindelin 5 siblings, 0 replies; 100+ messages in thread From: Johannes Schindelin @ 2007-10-17 21:08 UTC (permalink / raw) To: Tom Tobin; +Cc: Linus Torvalds, git Hi, On Wed, 17 Oct 2007, Tom Tobin wrote: > On Wed, 2007-10-17 at 11:54 -0700, Linus Torvalds wrote: > > > > On Wed, 17 Oct 2007, Tom Tobin wrote: > > > > > > Or is "unix developers" code for "my sample size of one"? > > > > Well, let's put it this way: that "sample" is the one that started the > > project. > > And therefore your choices become magically reasonable? Tom, you have to contribute way more code than you did, in order to be taken seriously with statements as these. Ciao, Dscho ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 18:54 ` Linus Torvalds 2007-10-17 19:33 ` Tom Tobin @ 2007-10-17 19:47 ` Jan Wielemaker 1 sibling, 0 replies; 100+ messages in thread From: Jan Wielemaker @ 2007-10-17 19:47 UTC (permalink / raw) To: Linus Torvalds; +Cc: Tom Tobin, git On Wednesday 17 October 2007 20:54, Linus Torvalds wrote: > On Wed, 17 Oct 2007, Tom Tobin wrote: > > Or is "unix developers" code for "my sample size of one"? > > Well, let's put it this way: that "sample" is the one that started the > project. > > I got to pick the license. Are you going to argue about that too? I got to > pick the way I wrote the code. Are you going to continue arguing about > that? > > The fact is, I don't see the people arguing for spaces having actually > *done* anything for git. So why are you arguing? Possibly because they do not want to cooperate :-) Anyway, it is mostly a Unix <-> the rest issue. In the Unix world all tools by default use 8-spaces per tab and although most of them can be told otherwise, nobody bothers. That way at least all code looks the same, regardless of spaces or tabs. Many editors are smart enough to create sequences N<TAB>+M<SPACE> for initial indentation to get consistent usage, but even if it isn't consistent patch and diff can be told to handle it. Outside the Unix world there appears to be little standard, so you receive files with any combination of tab distance, using tabs vs. spaces, etc. Most often I have to re-indent them before reading :-( I guess the most ideal situation is to use only tabs for initial indentation and spaces elsewhere, so changing the tab distance gets consistent layout. The drawback is that there is no room for `half indentation', so style conventions have to take care of that. Still, the main developers take the decision. If you don't like it, don't cooperate or fork. --- Jan ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 15:53 ` Linus Torvalds 2007-10-17 18:05 ` Johannes Schindelin 2007-10-17 18:25 ` Tom Tobin @ 2007-10-18 0:32 ` Jeff King 2007-10-18 0:59 ` Linus Torvalds 2 siblings, 1 reply; 100+ messages in thread From: Jeff King @ 2007-10-18 0:32 UTC (permalink / raw) To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, Oct 17, 2007 at 08:53:55AM -0700, Linus Torvalds wrote: > > Well, we just established that all-space is perfect, look-wise. > > But we also established that an all-space model is not stable, because any > unix developers will start adding tabs instead of spaces. In what way does an all-space model cause people to accidentally add tabs, but an all-tab model does not cause people to accidentally add spaces? -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 0:32 ` Jeff King @ 2007-10-18 0:59 ` Linus Torvalds 2007-10-18 2:45 ` Jeff King 0 siblings, 1 reply; 100+ messages in thread From: Linus Torvalds @ 2007-10-18 0:59 UTC (permalink / raw) To: Jeff King; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Jeff King wrote: > > In what way does an all-space model cause people to accidentally add > tabs, but an all-tab model does not cause people to accidentally add > spaces? It happens. We do de-spacification in the kernel occasionally when it is an annoyance. Usually it shows up in patches, though - exactly because code which adds spaces instead of tabs won't line up correctly in the diff. So it doesn't matter *which* one you use (all spaces or all tabs) in that sense. But clearly tabs are *way* more common at least in any UNIX project, and tabs really do have the advantage of being smaller. And smaller *is* faster. Do something like this on the kernel: GIT_PAGER= time git grep sched_fair and then do the same thing with the kernel sources blown up by 20% by de-tabification. Guess which one is 20% slower? And whoever said that disk space doesn't matter doesn't know what he is talking about. Disk space most *definitely* matters. Do the above test with a cold-cache case, and think what 20% more IO does to you (or 20% less disk cache). But no, the size issues are secondary, I'm not claiming anything else. Although I do suspect that historically, they have been primary, and have been the thing that has resulted in the fact that tabs are so commonly used. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 0:59 ` Linus Torvalds @ 2007-10-18 2:45 ` Jeff King 2007-10-18 3:03 ` david ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: Jeff King @ 2007-10-18 2:45 UTC (permalink / raw) To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote: > It happens. We do de-spacification in the kernel occasionally when it is > an annoyance. Usually it shows up in patches, though - exactly because > code which adds spaces instead of tabs won't line up correctly in the > diff. You have made this claim several times, and I really don't understand it. If I have 8 spaces, then a diff line will have either " ", "+", or "-" followed by 8 spaces. If I use a hard tab, then the tab will end up only taking up 7 spaces because of the nature of tabs. This might matter if I'm comparing non-diff code to diff code. But in a diff, _everything_ is indented by exactly one space, so it all lines up. Is there something I'm missing? > So it doesn't matter *which* one you use (all spaces or all tabs) in that > sense. Yes, I agree with that (even with an all-tabs policy, there are still mangled and incorrect patches that come in -- and the maintainer rejects or fixes them). Which was what I was trying to point out with my question (though I was also curious to hear your answer): all-space versus all-tab is largely a matter of preference. And that means that people who want git to change to _their_ preference are just being silly. > And smaller *is* faster. Do something like this on the kernel: > > GIT_PAGER= time git grep sched_fair > > and then do the same thing with the kernel sources blown up by 20% by > de-tabification. Guess which one is 20% slower? I was about to tell you that you're full of it, but there really is a slowdown: $ cd linux-2.6 $ GIT_PAGER= time git grep sched_fair >/dev/null 0.34user 0.94system 0:01.30elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+7548minor)pagefaults 0swaps $ find . -name .git -prune -o -type f | xargs perl -pi -e 's/\t/ /g' $ git-commit -a -m de-tabify $ git-repack -a -d $ GIT_PAGER= time git grep sched_fair >/dev/null 0.42user 1.06system 0:01.54elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (0major+7591minor)pagefaults 0swaps It's actually about 16%. Gah, I can't believe I've not only been sucked into a tab vs spaces discussion, but now I've actually wasted time doing a performance comparison on it. As an aside, that commit was enough to trigger a "git-gc --auto", which was my first experience with it. It's actually kind of annoying (especially since I was about to repack -a -d). -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 2:45 ` Jeff King @ 2007-10-18 3:03 ` david 2007-10-18 3:00 ` Jeff King 2007-10-18 3:13 ` Linus Torvalds 2007-10-18 4:52 ` On Tabs and Spaces Nicolas Pitre 2 siblings, 1 reply; 100+ messages in thread From: david @ 2007-10-18 3:03 UTC (permalink / raw) To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Jeff King wrote: > On Wed, Oct 17, 2007 at 05:59:27PM -0700, Linus Torvalds wrote: > >> It happens. We do de-spacification in the kernel occasionally when it is >> an annoyance. Usually it shows up in patches, though - exactly because >> code which adds spaces instead of tabs won't line up correctly in the >> diff. > > You have made this claim several times, and I really don't understand > it. If I have 8 spaces, then a diff line will have either " ", "+", or > "-" followed by 8 spaces. If I use a hard tab, then the tab will end up > only taking up 7 spaces because of the nature of tabs. > > This might matter if I'm comparing non-diff code to diff code. But in a > diff, _everything_ is indented by exactly one space, so it all lines up. > Is there something I'm missing? if the code uses a tab and the patch uses 8 spaces the two will not line up in the diff becouse in the diff output the tab is 'only 7 spaces; useing one or the other isn't the problem, it's the mixing of the two. David Lang ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 3:03 ` david @ 2007-10-18 3:00 ` Jeff King 2007-10-18 3:32 ` Linus Torvalds 0 siblings, 1 reply; 100+ messages in thread From: Jeff King @ 2007-10-18 3:00 UTC (permalink / raw) To: david; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, Oct 17, 2007 at 08:03:51PM -0700, david@lang.hm wrote: >> This might matter if I'm comparing non-diff code to diff code. But in a >> diff, _everything_ is indented by exactly one space, so it all lines up. >> Is there something I'm missing? > > if the code uses a tab and the patch uses 8 spaces the two will not line up > in the diff becouse in the diff output the tab is 'only 7 spaces; > > useing one or the other isn't the problem, it's the mixing of the two. Yes, obviously. The people who advocate mixing really _are_ objectively wrong. But I was talking about all-spaces versus all-tabs. -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 3:00 ` Jeff King @ 2007-10-18 3:32 ` Linus Torvalds 2007-10-18 4:17 ` Linus Torvalds 0 siblings, 1 reply; 100+ messages in thread From: Linus Torvalds @ 2007-10-18 3:32 UTC (permalink / raw) To: Jeff King; +Cc: david, Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Jeff King wrote: > > Yes, obviously. The people who advocate mixing really _are_ objectively > wrong. But I was talking about all-spaces versus all-tabs. If you really are all one-or-the-other, then everything is obviously fine, and spaces have somewhat stronger guarantees (I say "somewhat", because the line-up-guarantee of all-spaces is only guaranteed with fixed-width fonts, and hard-tab indents often look nicer in printouts, and are generally much more flexible in just how wide you make the indent *look*, ie hard-tabs at least *allow* people to see the indents in different ways, even if that will potentially mess up any alignment). But some mixing is inevitable, and at least in UNIX, the tendency is for tabs, not spaces, by default, so tabs have a much higher chance of *staying* mostly tabs, while anybody who uses spaces pretty much *will* get tabs inserted by just about any programming editor that isn't set up for python. So you always get _some_ amount of mixing, exactly because most editors won't show you the difference, and what people aren't aware of, they don't think about. There's no getting away from that, unless you actually enforce it with hooks (and in a distributed environment, even that isn't really going to fly, is it?). And if you *do* decide to enforce it with hooks, you now have issues like the fact that some files mustn't do it (autoconvert tabs to spaces in a Makefile, and it just stops working!), and others have somewhat subtle issues forcing your converter to be somewhat knowledgeable (trivial example: strings that are spread across multiple lines in C..) In general, if you do enforce it (which I personally think is not likely a good idea, but hey, it's up to the project), I'd *still* suggest going the way of enforcing hard-tabs, not spaces. As mentioned, space does matter, but hardtabs really are "friendlier", and if you're a vi user, you can do a :set tabstop=4 and if that's what you're used to, it will all look better to you. In contrast, all-spaces just sucks. It really has no redeeming values. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 3:32 ` Linus Torvalds @ 2007-10-18 4:17 ` Linus Torvalds 0 siblings, 0 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-18 4:17 UTC (permalink / raw) To: Jeff King; +Cc: david, Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Linus Torvalds wrote: > > [..] and if you're a vi user, you can do a ':set tabstop=4' btw, don't get me wrong. I think 8-char tabstops are much better, and would much prefer to really teach people not to indent too deeply (because six-deep indents really look ugly as hell with 8-char indents). So setting tabstops to smaller values is not something I think is good practice, but at least that way you can keep your dirty perversions to yourself, and don't have to admit to the world that you molest dogs and small children and use an inferior tab-stop. The rest of the world might notice occsionally when you don't hide your non-indentation tab-uses well enough, of course, but keep to block comments and spaces for non-indentation, and you'll be reasonably safe. However, if I see people actually having indentations six+ deep, I'll know that (a) you're likely a small-tab-misusing-deviant and (b) a horrible programmer. And then the tab-deviancy is the smaller problem. (Yes, we do have some cases of six+ deep indentations in the kernel. I'm happy to say that they are fairly rare, and yes, I'm personally convinced that the 8-wide indent level is part of it. It really *does* end up encouraging people to split things up and write nested cases as separate functions etc, because it simply becomes so obvious when things are going south..) Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 2:45 ` Jeff King 2007-10-18 3:03 ` david @ 2007-10-18 3:13 ` Linus Torvalds 2007-10-18 3:23 ` Jeff King 2007-10-18 4:52 ` On Tabs and Spaces Nicolas Pitre 2 siblings, 1 reply; 100+ messages in thread From: Linus Torvalds @ 2007-10-18 3:13 UTC (permalink / raw) To: Jeff King; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Jeff King wrote: > > You have made this claim several times, and I really don't understand > it. If I have 8 spaces, then a diff line will have either " ", "+", or > "-" followed by 8 spaces. If I use a hard tab, then the tab will end up > only taking up 7 spaces because of the nature of tabs. > > This might matter if I'm comparing non-diff code to diff code. But in a > diff, _everything_ is indented by exactly one space, so it all lines up. > Is there something I'm missing? Yes. You're missing the fact that some people have problems with editors. So they add a line, and they add *that* line with the wrong kind of indentation. And it shows up among the other lines like this (here the whole patch is indented): diff --git a/kernel/sched.c b/kernel/sched.c index 92721d1..1ecb164 100644 --- a/kernel/sched.c +++ b/kernel/sched.c @@ -127,6 +127,7 @@ static inline u32 sg_div_cpu_power(const struct sched_group *sg, u32 load) static inline void sg_inc_cpu_power(struct sched_group *sg, u32 val) { sg->__cpu_power += val; + wrong indentation here. sg->reciprocal_cpu_power = reciprocal_value(sg->__cpu_power); } #endif and so you see the fact that somebody messed up in the patch itself. It actually more often goes the other way: somebody may have messed up earlier, but did so *consistently* so it wasn't obvious when looking at the patch. And then somebody fixes one line, and now that one fixed line is indented correctly but differently. When it gets *too* bad, we just reindent the whole file, but more commonly when I notice it in a diff, I just edit that particular region or even just the diff itself in-place. Generally, it seldom comes to even that. Doing a git grep ' ' -- '*.c' (that's now eight spaces) returns quite a lot of lines, and it's generally not worth worrying about (not all of them are indentation - people do use spaces for lining things up etc - but a lot of it really is just indents done against the coding style). > I was about to tell you that you're full of it, but there really is a > slowdown: > [ ... ] > It's actually about 16%. I didn't even time it, and I called it at 20% without even counting any tabs. Why? Because it's inevitable! It so happens that "grep" has a lot of really clever heuristics, so that it is actually better at passing over characters that it knows cannot start the pattern you are searching for, so timing "grep" is actually quite complex in the general case. So I bet that if you had grepped for something that started with a space, you'd probably have found a bigger slowdown. But ignore all that complexity, and it really boils down to a really simple principle: bigger data sets are more expensive, and "linear slowdown" is actually almost the best possible case. Quite often, a bigger data set causes *worse* than a linear slowdown. It's very seldom the case that you grow some problem space and performance stays the same. > Gah, I can't believe I've not only been sucked into a tab vs spaces > discussion, but now I've actually wasted time doing a performance > comparison on it. Well, performance analysis isn't exactly a "waste". That "git grep" was something we spent some time trying to go fast (for example, doing the whole external grep tool thing because that thing is usually optimized to h*ll and back - so the execve() overhead is more than worth it). And it's a real workload. Maybe others don't use "git grep" quite as much as I do, but I do it *all* the time. Some other people probably use ctags or something, I personally prefer just a fast git grep. But the *exact* same issues will show up for "simple" things like "git bisect". One of the biggest costs of git bisect is actually checking out the source tree. If the source tree is on the order of 20% larger, what does that mean? So it doesn't matter if you have a terabyte disk. Source code size *still* matters. And 20% (or 16%) is more than a lot of other optimizations can help you save! > As an aside, that commit was enough to trigger a "git-gc --auto", which > was my first experience with it. It's actually kind of annoying > (especially since I was about to repack -a -d). Yeah, I don't think it's wonderful, but it might even be a good thing as a "hey, at least you are aware of the notion of GC now" kind of introduction to people (who then hopefully realize that they don't actually want automatic GC, but rather do it once a week or something). Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 3:13 ` Linus Torvalds @ 2007-10-18 3:23 ` Jeff King 2007-10-18 4:41 ` [PATCH] Add a message explaining that automatic GC is about to start koreth 0 siblings, 1 reply; 100+ messages in thread From: Jeff King @ 2007-10-18 3:23 UTC (permalink / raw) To: Linus Torvalds; +Cc: Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, Oct 17, 2007 at 08:13:23PM -0700, Linus Torvalds wrote: > Yes. > > You're missing the fact that some people have problems with editors. > > So they add a line, and they add *that* line with the wrong kind of > indentation. And it shows up among the other lines like this (here the > whole patch is indented): Oh. I thought you meant "if you have an all-spaces policy, your diffs will not look good." But what you meant was "when people screw up your policy by mixing tabs and spaces, your diffs will not look good." And that applies equally, whether they are screwing up your all-tabs or all-spaces setup (and I remain convinced that no matter what your policy, people _will_ screw it up). Thanks for the clarification. > It's very seldom the case that you grow some problem space and performance > stays the same. Yes. I wondered whether the increased size would really matter here, or if it would get lost in the noise of program startup and other activities. But in this case, it really does matter. > > Gah, I can't believe I've not only been sucked into a tab vs spaces > > discussion, but now I've actually wasted time doing a performance > > comparison on it. > Well, performance analysis isn't exactly a "waste". That "git grep" was No, it's not a waste. In the grand scheme of things, I don't actually care that much about the result, but hey, I think I may be the only person out of this gigantic thread to actually provide _numbers_. :) > Yeah, I don't think it's wonderful, but it might even be a good thing as a > "hey, at least you are aware of the notion of GC now" kind of introduction > to people (who then hopefully realize that they don't actually want > automatic GC, but rather do it once a week or something). It would have been nicer if it said something like "Your repository looks crufty. Running git-gc --auto..." using whatever terms users would be comfortable with. Instead, it just started with "Counting objects" and a long wait. I happen to know what that means, but I'm not sure how a git newbie would react (though it looked _much_ nicer because of Nico's recent terser progress patches). -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 3:23 ` Jeff King @ 2007-10-18 4:41 ` koreth 2007-10-18 4:44 ` Steven Grimm ` (2 more replies) 0 siblings, 3 replies; 100+ messages in thread From: koreth @ 2007-10-18 4:41 UTC (permalink / raw) To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git --- On Wed, Oct 17, 2007 at 11:23:07PM -0400, Jeff King wrote: > It would have been nicer if it said something like "Your repository > looks crufty. Running git-gc --auto..." using whatever terms users would > be comfortable with. Instead, it just started with "Counting objects" > and a long wait. And as an added bonus, we can tell people how to turn off automatic GC and how to invoke it by hand. builtin-gc.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/builtin-gc.c b/builtin-gc.c index 23ad2b6..b1159d6 100644 --- a/builtin-gc.c +++ b/builtin-gc.c @@ -211,6 +211,10 @@ int cmd_gc(int argc, const char **argv, const char *prefix) prune = 0; if (!need_to_gc()) return 0; + fprintf(stderr, "Packing your repository for optimum " + "performance. If you would rather run\n" + "\"git gc\" by hand, run \"git config gc.auto 0\" " + "to disable automatic cleanup.\n"); } if (pack_refs && run_command_v_opt(argv_pack_refs, RUN_GIT_CMD)) -- 1.5.3.rc2.4.g726f9 ^ permalink raw reply related [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 4:41 ` [PATCH] Add a message explaining that automatic GC is about to start koreth @ 2007-10-18 4:44 ` Steven Grimm 2007-10-18 5:01 ` Jeff King 2007-10-18 13:52 ` Brian Gernhardt 2 siblings, 0 replies; 100+ messages in thread From: Steven Grimm @ 2007-10-18 4:44 UTC (permalink / raw) To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git Sigh... Forgot to add: Signed-off-by: Steven Grimm <koreth@midwinter.com> ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 4:41 ` [PATCH] Add a message explaining that automatic GC is about to start koreth 2007-10-18 4:44 ` Steven Grimm @ 2007-10-18 5:01 ` Jeff King 2007-10-18 5:11 ` Shawn O. Pearce 2007-10-18 13:52 ` Brian Gernhardt 2 siblings, 1 reply; 100+ messages in thread From: Jeff King @ 2007-10-18 5:01 UTC (permalink / raw) To: koreth; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, Oct 17, 2007 at 09:41:43PM -0700, koreth@midwinter.com wrote: > And as an added bonus, we can tell people how to turn off automatic GC > and how to invoke it by hand. I like it, especially with the new progress patches. -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 5:01 ` Jeff King @ 2007-10-18 5:11 ` Shawn O. Pearce 0 siblings, 0 replies; 100+ messages in thread From: Shawn O. Pearce @ 2007-10-18 5:11 UTC (permalink / raw) To: Jeff King Cc: koreth, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git Jeff King <peff@peff.net> wrote: > On Wed, Oct 17, 2007 at 09:41:43PM -0700, koreth@midwinter.com wrote: > > > And as an added bonus, we can tell people how to turn off automatic GC > > and how to invoke it by hand. > > I like it, especially with the new progress patches. Me too. Its in my tree now. :-) -- Shawn. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 4:41 ` [PATCH] Add a message explaining that automatic GC is about to start koreth 2007-10-18 4:44 ` Steven Grimm 2007-10-18 5:01 ` Jeff King @ 2007-10-18 13:52 ` Brian Gernhardt 2007-10-18 14:16 ` Steven Grimm 2007-10-18 14:21 ` [PATCH] Add a message explaining that automatic GC is about to start Nicolas Pitre 2 siblings, 2 replies; 100+ messages in thread From: Brian Gernhardt @ 2007-10-18 13:52 UTC (permalink / raw) To: koreth Cc: Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote: > And as an added bonus, we can tell people how to turn off automatic GC > and how to invoke it by hand. > + fprintf(stderr, "Packing your repository for optimum " > + "performance. If you would rather run\n" > + "\"git gc\" by hand, run \"git config gc.auto 0\" " > + "to disable automatic cleanup.\n"); I'm not sure telling the users how to disable it every time it shows up is a good idea. gc --auto exists for the naive user, and suggesting they turn it off each time it happens will just result in... people turning it off, leading back to the performance issues that caused the feature to be installed in the first place. Perhaps a message more along the lines of "To avoid this, run "git gc" manually on a regular basis. See 'git help gc' for more information." ~~ Brian ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 13:52 ` Brian Gernhardt @ 2007-10-18 14:16 ` Steven Grimm 2007-10-18 18:08 ` Jeff King 2007-10-19 0:16 ` Shawn O. Pearce 2007-10-18 14:21 ` [PATCH] Add a message explaining that automatic GC is about to start Nicolas Pitre 1 sibling, 2 replies; 100+ messages in thread From: Steven Grimm @ 2007-10-18 14:16 UTC (permalink / raw) To: Brian Gernhardt Cc: Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git Brian Gernhardt wrote: > I'm not sure telling the users how to disable it every time it shows > up is a good idea. gc --auto exists for the naive user, and > suggesting they turn it off each time it happens will just result > in... people turning it off, leading back to the performance issues > that caused the feature to be installed in the first place. Perhaps a > message more along the lines of "To avoid this, run "git gc" manually > on a regular basis. See 'git help gc' for more information." That's a good point. Jeff / Shawn, do you agree with that? I'll come up with an alternate patch if so. -Steve ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 14:16 ` Steven Grimm @ 2007-10-18 18:08 ` Jeff King 2007-10-19 0:16 ` Shawn O. Pearce 1 sibling, 0 replies; 100+ messages in thread From: Jeff King @ 2007-10-18 18:08 UTC (permalink / raw) To: Steven Grimm Cc: Brian Gernhardt, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Thu, Oct 18, 2007 at 07:16:25AM -0700, Steven Grimm wrote: >> installed in the first place. Perhaps a message more along the lines of >> "To avoid this, run "git gc" manually on a regular basis. See 'git help >> gc' for more information." > > That's a good point. Jeff / Shawn, do you agree with that? I'll come up with > an alternate patch if so. Yes, that seems reasonable. I think the most important thing is that they realize that "git-gc" is responsible for what is happening. That should allow them to find more information in the documentation if they want (and Brian's suggestion points directly to the documentation, which is great). -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 14:16 ` Steven Grimm 2007-10-18 18:08 ` Jeff King @ 2007-10-19 0:16 ` Shawn O. Pearce 2007-10-19 1:12 ` [PATCH] git-gc: improve wording of --auto notification Jeff King 1 sibling, 1 reply; 100+ messages in thread From: Shawn O. Pearce @ 2007-10-19 0:16 UTC (permalink / raw) To: Steven Grimm Cc: Brian Gernhardt, Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git Steven Grimm <koreth@midwinter.com> wrote: > Brian Gernhardt wrote: > >I'm not sure telling the users how to disable it every time it shows > >up is a good idea. gc --auto exists for the naive user, and > >suggesting they turn it off each time it happens will just result > >in... people turning it off, leading back to the performance issues > >that caused the feature to be installed in the first place. Perhaps a > >message more along the lines of "To avoid this, run "git gc" manually > >on a regular basis. See 'git help gc' for more information." > > That's a good point. Jeff / Shawn, do you agree with that? I'll come up > with an alternate patch if so. Arrgh. I already have the original patch in this thread in my master so I can't rewind it. But yes, the argument Brian is making above makes a lot of sense and I like his proposed message even better than what I've already applied. A patch against spearce/master to revert the prior message and insert something that is perhaps more reasonable would be most appreciated. -- Shawn. ^ permalink raw reply [flat|nested] 100+ messages in thread
* [PATCH] git-gc: improve wording of --auto notification 2007-10-19 0:16 ` Shawn O. Pearce @ 2007-10-19 1:12 ` Jeff King 2007-10-19 1:24 ` Shawn O. Pearce 0 siblings, 1 reply; 100+ messages in thread From: Jeff King @ 2007-10-19 1:12 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Steven Grimm, Brian Gernhardt, git The previous message had too much of a "boy, you should really turn off this annoying gc" flair to it. Instead, let's make sure the user understands what is happening, that they can run it themselves, and where to find more info. Suggested by Brian Gernhardt. Signed-off-by: Jeff King <peff@peff.net> --- Shawn said: > A patch against spearce/master to revert the prior message and insert > something that is perhaps more reasonable would be most appreciated. Geez, you really _are_ the maintainer now, prodding your minions to write trivial patches for you. :) I don't see any point in reverting the other patch separately, since we can just improve the message. I tried not to use the word "avoid" since I think we don't want to imply that auto-gc sucks. It doesn't, but some people might prefer to run it manually, and we should let them know it's an option. I'm open to wording improvements. builtin-gc.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/builtin-gc.c b/builtin-gc.c index f99b212..3a2ca4f 100644 --- a/builtin-gc.c +++ b/builtin-gc.c @@ -206,9 +206,9 @@ int cmd_gc(int argc, const char **argv, const char *prefix) if (!need_to_gc()) return 0; fprintf(stderr, "Packing your repository for optimum " - "performance. If you would rather run\n" - "\"git gc\" by hand, run \"git config gc.auto 0\" " - "to disable automatic cleanup.\n"); + "performance. You may also\n" + "run \"git gc\" manually. See " + "\"git help gc\" for more information.\n"); } else { /* * Use safer (for shared repos) "-A" option to -- 1.5.3.4.1249.g895be-dirty ^ permalink raw reply related [flat|nested] 100+ messages in thread
* Re: [PATCH] git-gc: improve wording of --auto notification 2007-10-19 1:12 ` [PATCH] git-gc: improve wording of --auto notification Jeff King @ 2007-10-19 1:24 ` Shawn O. Pearce 2007-10-19 1:26 ` Jeff King 0 siblings, 1 reply; 100+ messages in thread From: Shawn O. Pearce @ 2007-10-19 1:24 UTC (permalink / raw) To: Jeff King; +Cc: Steven Grimm, Brian Gernhardt, git Jeff King <peff@peff.net> wrote: > Shawn said: > > A patch against spearce/master to revert the prior message and insert > > something that is perhaps more reasonable would be most appreciated. > > Geez, you really _are_ the maintainer now, prodding your minions to > write trivial patches for you. :) Heh. But didn't I just post a different trivial patch to the mailing list not 15 minutes ago? :-) > I don't see any point in reverting the > other patch separately, since we can just improve the message. I agree. No point in pissing in the snow multiple times over a simple language change. I was perhaps a little too aggressive in applying Steven's first patch. Which I also now see git-am actually split the From line incorrectly and doesn't actually show Steven's name in the author field. Arrgh. > I tried not to use the word "avoid" since I think we don't want to imply > that auto-gc sucks. It doesn't, but some people might prefer to run it > manually, and we should let them know it's an option. I'm open to > wording improvements. I think what you have is many times better. It doesn't tell the user that they can prevent having this activate at the wrong time by just running git-gc every so often, but if the message (and the subsequent packing itself) is annoying they'll read the manual entry and hopefully figure that out on their own. > fprintf(stderr, "Packing your repository for optimum " > + "performance. You may also\n" > + "run \"git gc\" manually. See " > + "\"git help gc\" for more information.\n"); -- Shawn. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] git-gc: improve wording of --auto notification 2007-10-19 1:24 ` Shawn O. Pearce @ 2007-10-19 1:26 ` Jeff King 0 siblings, 0 replies; 100+ messages in thread From: Jeff King @ 2007-10-19 1:26 UTC (permalink / raw) To: Shawn O. Pearce; +Cc: Steven Grimm, Brian Gernhardt, git On Thu, Oct 18, 2007 at 09:24:30PM -0400, Shawn O. Pearce wrote: > I think what you have is many times better. It doesn't tell the > user that they can prevent having this activate at the wrong time > by just running git-gc every so often, but if the message (and > the subsequent packing itself) is annoying they'll read the manual > entry and hopefully figure that out on their own. Yes, I tried many wordings of "this is annoying and you want to avoid it," but explaining the situation takes way too much time for such a commonly seen message. And I think some people will actually prefer it that way. BTW, the git-gc manpage needs some cleanup. Patches to follow. -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: [PATCH] Add a message explaining that automatic GC is about to start 2007-10-18 13:52 ` Brian Gernhardt 2007-10-18 14:16 ` Steven Grimm @ 2007-10-18 14:21 ` Nicolas Pitre 1 sibling, 0 replies; 100+ messages in thread From: Nicolas Pitre @ 2007-10-18 14:21 UTC (permalink / raw) To: Brian Gernhardt Cc: koreth, Jeff King, Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Thu, 18 Oct 2007, Brian Gernhardt wrote: > > On Oct 18, 2007, at 12:41 AM, koreth@midwinter.com wrote: > > > And as an added bonus, we can tell people how to turn off automatic GC > > and how to invoke it by hand. > > > + fprintf(stderr, "Packing your repository for optimum " > > + "performance. If you would rather run\n" > > + "\"git gc\" by hand, run \"git config gc.auto 0\" " > > + "to disable automatic cleanup.\n"); > > I'm not sure telling the users how to disable it every time it shows up is a > good idea. gc --auto exists for the naive user, and suggesting they turn it > off each time it happens will just result in... people turning it off, > leading back to the performance issues that caused the feature to be installed > in the first place. Perhaps a message more along the lines of "To avoid this, > run "git gc" manually on a regular basis. See 'git help gc' for more > information." This is indeed a good point. And for those who start repacking manually then the automatic repacking will very rarely trigger, reducing the need for turning automatic repacking off anyway. Nicolas ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 2:45 ` Jeff King 2007-10-18 3:03 ` david 2007-10-18 3:13 ` Linus Torvalds @ 2007-10-18 4:52 ` Nicolas Pitre 2007-10-18 4:54 ` Jeff King 2 siblings, 1 reply; 100+ messages in thread From: Nicolas Pitre @ 2007-10-18 4:52 UTC (permalink / raw) To: Jeff King; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Wed, 17 Oct 2007, Jeff King wrote: > As an aside, that commit was enough to trigger a "git-gc --auto", which > was my first experience with it. It's actually kind of annoying > (especially since I was about to repack -a -d). Well, you actually touched every files in the tree, and there are about 22K of them. this, plus the tree objects leading to them, your commit certainly did create an unusual amount of loose objects. Repacking them will inevitably take a wile. Nicolas ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 4:52 ` On Tabs and Spaces Nicolas Pitre @ 2007-10-18 4:54 ` Jeff King 2007-10-18 4:55 ` Jeff King 0 siblings, 1 reply; 100+ messages in thread From: Jeff King @ 2007-10-18 4:54 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Thu, Oct 18, 2007 at 12:52:59AM -0400, Nicolas Pitre wrote: > Well, you actually touched every files in the tree, and there are about > 22K of them. this, plus the tree objects leading to them, your commit > certainly did create an unusual amount of loose objects. Repacking them > will inevitably take a wile. Yes, I know. I wasn't complaining so much about the speed, but rather the behavior of "git-gc" running while I was in the middle of trying to accomplish something else (I hadn't seen it before, because I generally keep my repos fairly packed). -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 4:54 ` Jeff King @ 2007-10-18 4:55 ` Jeff King 0 siblings, 0 replies; 100+ messages in thread From: Jeff King @ 2007-10-18 4:55 UTC (permalink / raw) To: Nicolas Pitre; +Cc: Linus Torvalds, Luke Lu, Christer Weinigel, Tom Tobin, git On Thu, Oct 18, 2007 at 12:54:53AM -0400, Jeff King wrote: > > Well, you actually touched every files in the tree, and there are about > > 22K of them. this, plus the tree objects leading to them, your commit > > certainly did create an unusual amount of loose objects. Repacking them > > will inevitably take a wile. > > Yes, I know. I wasn't complaining so much about the speed, but rather > the behavior of "git-gc" running while I was in the middle of trying to > accomplish something else (I hadn't seen it before, because I generally > keep my repos fairly packed). But if you are trying to say that my case is pathological, then yes. -Peff ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 7:17 ` Luke Lu 2007-10-17 9:09 ` Michael Witten 2007-10-17 15:53 ` Linus Torvalds @ 2007-10-17 16:08 ` David Kastrup 2007-10-17 17:44 ` Nicolas Pitre 2007-10-17 17:51 ` Sean 2 siblings, 2 replies; 100+ messages in thread From: David Kastrup @ 2007-10-17 16:08 UTC (permalink / raw) To: git Luke Lu <git@vicaya.com> writes: > But I still haven't seen any compelling arguments against the "all > space" case, other than "people will screw it up into mixed spaces", > which is really a straw man, as many multi-platform projects > enforced the all-space policy easily by using a pre-commit hook in > maintainers' repository. All-space indentation renders the binary delta algorithm git uses for compression of packs slow and partly inoperative (all sequences of 16 spaces share the same finger print, and the number of identical finger prints for which the file information is kept is reduced to 64). > The only downside of all-space is a moderate space bloat in source, > which is insignificant, all things considered. It will also slow down git's packing and make it produce worse results. > I agree that "8-character tabs are the gold standard", only for the > tabstop==8 part but not the indent==tab part. For me the question > is: is it really so unreasonable to just say "all-space is the holy > grail"? Yes. -- David Kastrup ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 16:08 ` David Kastrup @ 2007-10-17 17:44 ` Nicolas Pitre 2007-10-17 19:52 ` David Kastrup 2007-10-17 17:51 ` Sean 1 sibling, 1 reply; 100+ messages in thread From: Nicolas Pitre @ 2007-10-17 17:44 UTC (permalink / raw) To: David Kastrup; +Cc: git On Wed, 17 Oct 2007, David Kastrup wrote: > Luke Lu <git@vicaya.com> writes: > > > But I still haven't seen any compelling arguments against the "all > > space" case, other than "people will screw it up into mixed spaces", > > which is really a straw man, as many multi-platform projects > > enforced the all-space policy easily by using a pre-commit hook in > > maintainers' repository. > > All-space indentation renders the binary delta algorithm git uses for > compression of packs slow and partly inoperative (all sequences of 16 > spaces share the same finger print, and the number of identical finger > prints for which the file information is kept is reduced to 64). But sequences of 16 spaces are unlikely to land on 16-byte boundaries all the time in the file so adjacent data to those 16-space blocks will still provide good hashing. > > The only downside of all-space is a moderate space bloat in source, > > which is insignificant, all things considered. > > It will also slow down git's packing and make it produce worse > results. If that was effectively the case then it is Git that had to be fixed and not the way people write code. Git should cope with the data it is fed and not the other way around. And this is completely orthogonal to the policy of using hard tabs or spaces in source code, so I'm clearly _not_ providing any argument to that discussion one way or the other here. Nicolas ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 17:44 ` Nicolas Pitre @ 2007-10-17 19:52 ` David Kastrup 0 siblings, 0 replies; 100+ messages in thread From: David Kastrup @ 2007-10-17 19:52 UTC (permalink / raw) To: Nicolas Pitre; +Cc: git Nicolas Pitre <nico@cam.org> writes: > On Wed, 17 Oct 2007, David Kastrup wrote: > >> Luke Lu <git@vicaya.com> writes: >> >> > But I still haven't seen any compelling arguments against the "all >> > space" case, other than "people will screw it up into mixed spaces", >> > which is really a straw man, as many multi-platform projects >> > enforced the all-space policy easily by using a pre-commit hook in >> > maintainers' repository. >> >> All-space indentation renders the binary delta algorithm git uses for >> compression of packs slow and partly inoperative (all sequences of 16 >> spaces share the same finger print, and the number of identical finger >> prints for which the file information is kept is reduced to 64). > > But sequences of 16 spaces are unlikely to land on 16-byte boundaries > all the time in the file so adjacent data to those 16-space blocks will > still provide good hashing. Half of the three-tab equivalents and all of the four-tab equivalents contain a 16-byte space sequence on the tested boundary. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-17 16:08 ` David Kastrup 2007-10-17 17:44 ` Nicolas Pitre @ 2007-10-17 17:51 ` Sean 1 sibling, 0 replies; 100+ messages in thread From: Sean @ 2007-10-17 17:51 UTC (permalink / raw) To: David Kastrup; +Cc: git On Wed, October 17, 2007 12:08 pm, David Kastrup said: > > All-space indentation renders the binary delta algorithm git uses for > compression of packs slow and partly inoperative (all sequences of 16 > spaces share the same finger print, and the number of identical finger > prints for which the file information is kept is reduced to 64). You seem to have identified a weakness in Git's design rather than an argument against using all-space indentation. Personally I find it counter-productive and annoying to work in space-indented source code. But let's be honest, this "issue" is mostly about familiarity and comfort rather than some deep objective truth. Sean ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 23:05 ` Linus Torvalds 2007-10-16 23:51 ` Christer Weinigel @ 2007-10-17 5:56 ` David Kastrup 1 sibling, 0 replies; 100+ messages in thread From: David Kastrup @ 2007-10-17 5:56 UTC (permalink / raw) To: git Linus Torvalds <torvalds@linux-foundation.org> writes: > On Tue, 16 Oct 2007, Tom Tobin wrote: >> >> But you then dismiss out of hand the option of using all spaces > > I do indeed. I don't think it's sensible. Actually, it seriously degrades (both performance and savings) deltifying once you reach an indentation of 16. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:20 ` Linus Torvalds 2007-10-16 19:36 ` Mike Hommey 2007-10-16 20:18 ` Tom Tobin @ 2007-10-16 20:56 ` Sam Ravnborg 2007-10-18 3:31 ` Paul Wankadia 2007-10-18 4:36 ` Dmitry Potapov 4 siblings, 0 replies; 100+ messages in thread From: Sam Ravnborg @ 2007-10-16 20:56 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jari Aalto, git On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote: > > The answer is *also* not "tabs are just for initial code > indents", because not only will most sane editors never even show the > difference, it's simply not how people work. So such a rule about > invisible things doesn't work. It is insane to *require* diciplined people to use tabs for more than code indents. If you insist on using tabs all over the place - fine with me. But do not frown upon me and other diciplined people becasue we use spaces to make sure our arguments to a function call is properly aligned in a tab=10,tab=8,tab=2 environment. The arguments "tabs are always 8 spaces properly aligned" is just to reach the lowest common denominator around developers. And frankly there are some that do better than that. The root casue are the stupid editors that does not make it easy to be diciplined and thats where the errors come from and all the stupid rules like the above. Sam ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:20 ` Linus Torvalds ` (2 preceding siblings ...) 2007-10-16 20:56 ` Sam Ravnborg @ 2007-10-18 3:31 ` Paul Wankadia 2007-10-18 4:22 ` Linus Torvalds 2007-10-18 4:36 ` Dmitry Potapov 4 siblings, 1 reply; 100+ messages in thread From: Paul Wankadia @ 2007-10-18 3:31 UTC (permalink / raw) To: git Linus Torvalds <torvalds <at> linux-foundation.org> writes: > The only sane solution is the one the kernel and git have always used: > tabs are 8 spaces wide, and anybody who disagrees can go screw themselves. I hope and pray that you are parodied on "South Park" someday. ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-18 3:31 ` Paul Wankadia @ 2007-10-18 4:22 ` Linus Torvalds 0 siblings, 0 replies; 100+ messages in thread From: Linus Torvalds @ 2007-10-18 4:22 UTC (permalink / raw) To: Paul Wankadia; +Cc: git On Thu, 18 Oct 2007, Paul Wankadia wrote: > > I hope and pray that you are parodied on "South Park" someday. Isn't that what every person aspires to in the end? Maybe I should start a kooky religion, then I'd be a shoo-in. Linus ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 19:20 ` Linus Torvalds ` (3 preceding siblings ...) 2007-10-18 3:31 ` Paul Wankadia @ 2007-10-18 4:36 ` Dmitry Potapov 4 siblings, 0 replies; 100+ messages in thread From: Dmitry Potapov @ 2007-10-18 4:36 UTC (permalink / raw) To: Linus Torvalds; +Cc: Jari Aalto, git On Tue, Oct 16, 2007 at 12:20:50PM -0700, Linus Torvalds wrote: > The answer is *also* not "tabs are just for initial code > indents", Unfortunately, it leads to some problems. For example, you can type: git blame alloc.c 2c1cbec1 (Linus Torvalds 2007-04-16 22:10:19 -0700 21) #define DEFINE_ALLOCATOR(name, type) \ 855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 22) static unsigned int name##_allocs; \ 100c5f3b (Linus Torvalds 2007-04-16 22:11:43 -0700 23) void *alloc_##name##_node(void) \ 855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 24) { \ 855419f7 (Linus Torvalds 2006-06-19 10:44:15 -0700 25) static int nr; \ and see that the end of line 23 does not look right. Because of that, I prefer tabs for initial code indents and spaces in other places. Of course, my preferences are irrelevant when it comes to someone else's project, and I can easily use whatever style it takes to get things done. It is just that "use tabs elsewhere and everything will be fine as long as you have the standard tab setting" is not exactly correct. The rest is people's preferences and habits... Dmitry ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 15:26 ` Jeffrey C. Ollie 2007-10-16 15:51 ` Michael Witten @ 2007-10-16 17:23 ` Andreas Ericsson 2007-10-16 18:34 ` Jan-Benedict Glaw 1 sibling, 1 reply; 100+ messages in thread From: Andreas Ericsson @ 2007-10-16 17:23 UTC (permalink / raw) To: Jeffrey C. Ollie; +Cc: Adam Piatyszek, Lars Hjemli, Michael Witten, git Jeffrey C. Ollie wrote: > On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote: >> And if one change the tab size, it will result in a messy alignment in >> line 5. > > Which is why one should never should change the tab size from anything > but 8. > I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's not as if I've got much choice if I want to be able to see anything on the screen. Some whitespace-damaged places look ugly, but it's usually not too bad. >> I guess there is no ideal solution for this in Emacs. > > Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-mode > nil)". This will force emacs to always use spaces to indent. > ... but don't do this when hacking on Linux or git. Thanks -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 17:23 ` Andreas Ericsson @ 2007-10-16 18:34 ` Jan-Benedict Glaw 2007-10-16 18:51 ` Andreas Ericsson 0 siblings, 1 reply; 100+ messages in thread From: Jan-Benedict Glaw @ 2007-10-16 18:34 UTC (permalink / raw) To: Andreas Ericsson Cc: Jeffrey C. Ollie, Adam Piatyszek, Lars Hjemli, Michael Witten, git [-- Attachment #1: Type: text/plain, Size: 887 bytes --] On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson <ae@op5.se> wrote: > Jeffrey C. Ollie wrote: > > On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote: > > > And if one change the tab size, it will result in a messy alignment in > > > line 5. > > > > Which is why one should never should change the tab size from anything > > but 8. > > I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's You fir 768 lines of text and 1024 chars per line to such a small display and still argue about too large tabs? SCNR, JBG -- Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481 Signature of: Ich hatte in letzter Zeit ein bißchen viel Realitycheck. the second : Langsam möchte ich mal wieder weiterträumen können. -- Maximilian Wilhelm (18. Mai 2006, #lug-owl.de) [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 18:34 ` Jan-Benedict Glaw @ 2007-10-16 18:51 ` Andreas Ericsson 0 siblings, 0 replies; 100+ messages in thread From: Andreas Ericsson @ 2007-10-16 18:51 UTC (permalink / raw) To: Jan-Benedict Glaw Cc: Jeffrey C. Ollie, Adam Piatyszek, Lars Hjemli, Michael Witten, git Jan-Benedict Glaw wrote: > On Tue, 2007-10-16 19:23:46 +0200, Andreas Ericsson <ae@op5.se> wrote: >> Jeffrey C. Ollie wrote: >>> On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote: >>>> And if one change the tab size, it will result in a messy alignment in >>>> line 5. >>> Which is why one should never should change the tab size from anything >>> but 8. >> I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's > > You fir 768 lines of text and 1024 chars per line to such a small > display and still argue about too large tabs? > If by "char" you mean "pixel", then yes. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 ^ permalink raw reply [flat|nested] 100+ messages in thread
* Re: On Tabs and Spaces 2007-10-16 6:45 On Tabs and Spaces Michael Witten 2007-10-16 7:04 ` Shawn O. Pearce 2007-10-16 8:30 ` Adam Piatyszek @ 2007-10-20 13:54 ` Robin Rosenberg 2 siblings, 0 replies; 100+ messages in thread From: Robin Rosenberg @ 2007-10-20 13:54 UTC (permalink / raw) To: Michael Witten; +Cc: git [-- Attachment #1: Type: text/plain, Size: 2947 bytes --] tisdag 16 oktober 2007 skrev Michael Witten: > What are the rules about tabs and spaces in source code? > > I'm having a terrible time with formatting, > especially in the perl scripts; there is a > mix of spaces and tabs. > > from what I can deduce, single tabs are used > to introduce the equivalent of 8 spaces while > 4 explicit spaces are used for half a tab. A looong time ago I worked with a system that did not have *this* problem. The code had a straight left margin. No indent. The code was initially written just after the origin of time_t (content, not name) and that it was written on punched cards probably explains the left margin, efter all you can indent the cards if you like to. I "accidentally" did indent code once, but only once, since I got a lot of complains from others about not following coding standards. My solution was to write a Brief macro to indent the code before working on it and undent before submitting my work to test. We never had a discussion on tabs vs spaces. Btw, some of that code was "logically" indented 22 levels. I'm still amazed att those long sheets of code people annotated with pencil to discover the logical structure. So it is possble to simply not care about tabs and spaces, except where there is a syntactic difference. Fast-formward twenty years and back to the topic. I think it is ok to start or end a *big* series of changes with a re-format patch, iff the series already introduces a *lot* of changes. In the previously submitted and rejected patch to cvsexportcommit this was not the case, I rewrote it heavily and that would have been a window for for reformatting, but I didn't see a need, probably because I used emacs and probably the original author too. Now I realize the file *is* actually indented inconsistently. Add to that that I am responsible for some of it. Next person to do any major work on it should submit a fix-indentation patch very much like the one MIchael did. The problem with reviewing such patches still exists, it is not possible to just read such patches, one has to apply them and verify them with other tools. I've been through enough many bracket and indentation discussions to see that it really doesn't matter as much what style is used as long as the same style is used throughout a whole source file. There are some coding styles that works bad with the patch/apply style submitting code, but those are not an issue here. As for TAB size. The most authoritative read "stupid") programs on the issue, i.e. cat (unix) and type (dos/windows) agree that tab stops are located at every eight position starting (8,16 etc). Attached is an updated version of a script I've been using lately to clean up commits. First it only removed trailing whitespace, but after this thread I changed it to (try to) tabify changes. Should we use such scripts more actively to root out inconsistencies a patch at a time? -- robin [-- Attachment #2: washammend --] [-- Type: application/x-shellscript, Size: 636 bytes --] [-- Attachment #3: washtrailing --] [-- Type: application/x-shellscript, Size: 535 bytes --] ^ permalink raw reply [flat|nested] 100+ messages in thread
end of thread, other threads:[~2007-10-22 3:40 UTC | newest] Thread overview: 100+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-10-16 6:45 On Tabs and Spaces Michael Witten 2007-10-16 7:04 ` Shawn O. Pearce 2007-10-16 7:27 ` Michael Witten 2007-10-16 17:20 ` Andreas Ericsson 2007-10-16 17:40 ` Sam Ravnborg 2007-10-16 23:09 ` Petr Baudis 2007-10-17 3:41 ` David 2007-10-17 11:32 ` Andy Parkins 2007-10-16 8:30 ` Adam Piatyszek 2007-10-16 9:04 ` Lars Hjemli 2007-10-16 10:16 ` Adam Piatyszek 2007-10-16 15:26 ` Jeffrey C. Ollie 2007-10-16 15:51 ` Michael Witten 2007-10-16 17:06 ` Jari Aalto 2007-10-16 19:20 ` Linus Torvalds 2007-10-16 19:36 ` Mike Hommey 2007-10-16 19:47 ` Linus Torvalds 2007-10-16 19:51 ` Linus Torvalds 2007-10-16 20:32 ` Matthieu Moy 2007-10-16 20:18 ` Tom Tobin 2007-10-16 23:05 ` Linus Torvalds 2007-10-16 23:51 ` Christer Weinigel 2007-10-17 0:45 ` Linus Torvalds 2007-10-17 3:08 ` Michael Witten 2007-10-17 3:29 ` Linus Torvalds 2007-10-17 7:17 ` Luke Lu 2007-10-17 9:09 ` Michael Witten 2007-10-17 10:03 ` Luke Lu 2007-10-17 10:21 ` Nikolai Weibull 2007-10-17 11:23 ` Michael Witten 2007-10-17 22:02 ` Jari Aalto 2007-10-17 22:36 ` Andreas Ericsson 2007-10-17 23:38 ` Jari Aalto 2007-10-18 4:31 ` Dmitry Torokhov 2007-10-18 8:19 ` Jari Aalto 2007-10-18 11:34 ` Petr Baudis 2007-10-18 11:39 ` Nikolai Weibull 2007-10-22 3:39 ` Miles Bader 2007-10-18 7:15 ` David Kågedal 2007-10-18 5:42 ` Mike Hommey 2007-10-18 10:36 ` Jari Aalto 2007-10-17 15:53 ` Linus Torvalds 2007-10-17 18:05 ` Johannes Schindelin 2007-10-17 18:25 ` Tom Tobin 2007-10-17 18:54 ` Linus Torvalds 2007-10-17 19:33 ` Tom Tobin 2007-10-17 19:44 ` Linus Torvalds 2007-10-17 19:48 ` Nicolas Pitre 2007-10-17 19:52 ` Josh England 2007-10-17 19:53 ` Linus Torvalds 2007-10-17 21:21 ` Christer Weinigel 2007-10-17 22:03 ` Linus Torvalds 2007-10-18 6:25 ` David Kastrup 2007-10-17 22:11 ` Johannes Schindelin 2007-10-17 23:17 ` Christer Weinigel 2007-10-17 23:44 ` Johannes Schindelin 2007-10-18 0:31 ` Christer Weinigel 2007-10-18 6:02 ` Andreas Ericsson 2007-10-18 7:12 ` David Kågedal 2007-10-17 23:53 ` Linus Torvalds 2007-10-17 20:31 ` David Kastrup 2007-10-17 21:08 ` Johannes Schindelin 2007-10-17 19:47 ` Jan Wielemaker 2007-10-18 0:32 ` Jeff King 2007-10-18 0:59 ` Linus Torvalds 2007-10-18 2:45 ` Jeff King 2007-10-18 3:03 ` david 2007-10-18 3:00 ` Jeff King 2007-10-18 3:32 ` Linus Torvalds 2007-10-18 4:17 ` Linus Torvalds 2007-10-18 3:13 ` Linus Torvalds 2007-10-18 3:23 ` Jeff King 2007-10-18 4:41 ` [PATCH] Add a message explaining that automatic GC is about to start koreth 2007-10-18 4:44 ` Steven Grimm 2007-10-18 5:01 ` Jeff King 2007-10-18 5:11 ` Shawn O. Pearce 2007-10-18 13:52 ` Brian Gernhardt 2007-10-18 14:16 ` Steven Grimm 2007-10-18 18:08 ` Jeff King 2007-10-19 0:16 ` Shawn O. Pearce 2007-10-19 1:12 ` [PATCH] git-gc: improve wording of --auto notification Jeff King 2007-10-19 1:24 ` Shawn O. Pearce 2007-10-19 1:26 ` Jeff King 2007-10-18 14:21 ` [PATCH] Add a message explaining that automatic GC is about to start Nicolas Pitre 2007-10-18 4:52 ` On Tabs and Spaces Nicolas Pitre 2007-10-18 4:54 ` Jeff King 2007-10-18 4:55 ` Jeff King 2007-10-17 16:08 ` David Kastrup 2007-10-17 17:44 ` Nicolas Pitre 2007-10-17 19:52 ` David Kastrup 2007-10-17 17:51 ` Sean 2007-10-17 5:56 ` David Kastrup 2007-10-16 20:56 ` Sam Ravnborg 2007-10-18 3:31 ` Paul Wankadia 2007-10-18 4:22 ` Linus Torvalds 2007-10-18 4:36 ` Dmitry Potapov 2007-10-16 17:23 ` Andreas Ericsson 2007-10-16 18:34 ` Jan-Benedict Glaw 2007-10-16 18:51 ` Andreas Ericsson 2007-10-20 13:54 ` Robin Rosenberg
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).