{"thread":{"id":"2644","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","startedAt":"2005-11-22T03:20:14Z","lastAt":"2005-11-22T20:13:01Z","messageCount":9,"participants":["linux@horizon.com","Linus Torvalds","Andreas Ericsson","Nikolai Weibull","Adrien Beau"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12507","messageId":"20051122032014.32539.qmail@science.horizon.com","threadId":"2644","inReplyTo":null,"subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2005-11-22T03:20:14Z","receivedAt":"2005-11-22T03:20:14Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> The main reason I don't like indentation is that it tends to have strange \n> rules for \"tab\". Some people (incorrectly, of course) think that tabs are \n> not at fixed 8-byte things, so deciding the indentation of a tab often \n> ends up either disallowing tabs altogether (bad) or having other strange \n> rules (disallowing spaces).\n> \n> So I'm not religiously opposed to it, but I find it to be less than \n> optimal.\n\nActually, most indentation-sensitive languages have a simpler solution:\nthey don't try to convert whitespace strings to a number like \"horizontal\nposition\"; they just compare strings.\n\nEach line must either have the same indentation string as some active\nscope, or its indentation must have the current innermost scope as a\nprefix, in which case it introduces a new scope.\n\nThis allows anything except for\n\nfoo\t\t# No prefix\n    bar\t\t# 4 spaces prefix\n\tbaz\t# tab prefix: illegal!\n\nThe \"baz\" line would have to begin with 4 spaces to be legal.\nThey could be followed by 4 more spaces, or a tab, or any other\nwhitespace pattern.\n\nIt's also possible to combine the two, as Haskell does.  Haskell inserts\nopen braces automatically if there is no such punctuation between two\nlines with differing indentation, but if you supply a brace explicitly,\nyou can do whatever indentation you like.  (And the close brace must be\nexplicit if the open brace is, of course.)\n"},{"id":"12508","messageId":"Pine.LNX.4.64.0511211931350.13959@g5.osdl.org","threadId":"2644","inReplyTo":"20051122032014.32539.qmail@science.horizon.com","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-22T03:38:12Z","receivedAt":"2005-11-22T03:38:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 21 Nov 2005, linux@horizon.com wrote:\n> \n> Actually, most indentation-sensitive languages have a simpler solution:\n> they don't try to convert whitespace strings to a number like \"horizontal\n> position\"; they just compare strings.\n\nYes, but that doesn't really change the problem: you can't _visually_ see \nwhat is wrong in most editors (some editors end up showing tabs as \nsomething that isn't quite whitespace, but that's also really irritating).\n\nThis is like Makefiles: if you have spaces in the wrong place, it may all \n_look_ fine, but the Makefile just doesn't work. Really irritating.\n\nAnd obviously using the file will show the problem (the parser will \ncomplain with a nice line number and readable error, hopefully), but I \npersonally find that to just be too damn late. By then, you're already \nirritated.\n\nSo I like the notion of depending on indentation, but I just feel it falls \ndown in practice. \n\nOf course, since I believe that tabs are always exactly 8 characters, I'd \nalso be perfectly happy to just declare that anybody who disagrees with me \nis a moron and deserves to die (*).\n\n\t\tLinus\n\n(*) That's obviously true of _anything_ that people disagree with me on,\nbut at the same time, I have this nagging suspicion that it's just better \nto not depend on indentation.\n"},{"id":"12509","messageId":"20051122041843.9436.qmail@science.horizon.com","threadId":"2644","inReplyTo":"Pine.LNX.4.64.0511211931350.13959@g5.osdl.org","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2005-11-22T04:18:43Z","receivedAt":"2005-11-22T04:18:43Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> This is like Makefiles: if you have spaces in the wrong place, it may all \n> _look_ fine, but the Makefile just doesn't work. Really irritating.\n\nMakefiles are more annoying because spaces instead of tabs can cause\nthem to work *differently*.  It's hard to write syntax that will\nactually do that, but the parser ahs to go past the problem a bit to\nreally figure it out, so it can't print a nice error message.\n\nWith the strict prefix convention, the parser can produce excellent\nerror messages.\n\n> And obviously using the file will show the problem (the parser will \n> complain with a nice line number and readable error, hopefully), but I \n> personally find that to just be too damn late. By then, you're already \n> irritated.\n>\n> So I like the notion of depending on indentation, but I just feel it falls \n> down in practice. \n\nSo you're a crotchety old fart already, unable to learn new things?\n\nIt irritates you the first few times until you learn to do it right in \nfirst place, just like it irritates most beginning C programmers that the\ncompiler keeps complaining about missing semicolons.\n\nComputers will be annoying about syntax until they learn to do what\nI want them to do rather than what I tell them to do, at which point\nthey'll be smart enough to start being annoying by doing what they want\nto to instead of what I want them to do.\n\n> Of course, since I believe that tabs are always exactly 8 characters, I'd \n> also be perfectly happy to just declare that anybody who disagrees with me \n> is a moron and deserves to die (*).\n\nI agree on the One True Tab Spacing, but I fear I heretically\ndisagree with you about the whole NO_IRQ thing, so I guess I'll just\nhave to take your advice and start stalking you with eugenic intent.\n\n[Briefly: what hardware conventions are, and particularly how many\nof those hardware devices exist in the world, is irrelevant.  We have\nexistence proofs of hardware that uses 0 for \"no IRQ\" and hardware that\naccepts 0 as a valid IRQ.  dev->irq is a freaking *software convention*.\nWhat matters is the development and maintenance burden of translating\nthat convention into all the different hardware out there.  And frankly\nconverting between \"0 is valid\" and \"0 is invalid\" affects a lot more\ncode paths than converting between \"0 is invalid\" and \"-1 is invalid\"\nfor a couple of specific hardware devices.  Particularly if you\nwant various kernel messages and /proc/interrupts to look right.\n\nHell, I could argue that having the most common hardware exercise the\nlongest code paths is a good thing, because that puts the code that\nneeds the most testing where it'll get it.]\n\n\nSeriously, you could always have it print warning messages but try to\nkeep going by assuming 8 space tabs so that at least you can postpone\nfixing the problem until your current train of thought has pulled into\nthe station.\n"},{"id":"12526","messageId":"4382D31E.40400@op5.se","threadId":"2644","inReplyTo":"20051122032014.32539.qmail@science.horizon.com","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-22T08:13:18Z","receivedAt":"2005-11-22T08:13:18Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"linux@horizon.com wrote:\n> Actually, most indentation-sensitive languages have a simpler solution:\n> they don't try to convert whitespace strings to a number like \"horizontal\n> position\"; they just compare strings.\n> \n> Each line must either have the same indentation string as some active\n> scope, or its indentation must have the current innermost scope as a\n> prefix, in which case it introduces a new scope.\n> \n> This allows anything except for\n> \n> foo\t\t# No prefix\n>     bar\t\t# 4 spaces prefix\n> \tbaz\t# tab prefix: illegal!\n> \n> The \"baz\" line would have to begin with 4 spaces to be legal.\n> They could be followed by 4 more spaces, or a tab, or any other\n> whitespace pattern.\n> \n\nSo, would this be considered legal or would it barf on baz?\n\nfoo\t\t# No prefix\n\tbar\t# tab prefix\n        baz     # 8 spaces prefix\n\nMost people have tabsize at 8. Some don't. Some editors insert spaces\ninstead of tabs while others don't. If we just match strings we'll\nend up with users sending bug-reports by cut'n pasting their perfectly\nvalid-looking config which mixes tabs and spaces just because it's\nbeen edited by people using different editors.\n\nReal fun would be if the mta sends tabs as spaces. Then there'd\nbe no way at all of telling if the config *is* valid or not.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12529","messageId":"4382DFDA.6040306@op5.se","threadId":"2644","inReplyTo":"20051122041843.9436.qmail@science.horizon.com","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-22T09:07:38Z","receivedAt":"2005-11-22T09:07:38Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"linux@horizon.com wrote:\n>>This is like Makefiles: if you have spaces in the wrong place, it may all \n>>_look_ fine, but the Makefile just doesn't work. Really irritating.\n> \n> \n> Makefiles are more annoying because spaces instead of tabs can cause\n> them to work *differently*.  It's hard to write syntax that will\n> actually do that, but the parser ahs to go past the problem a bit to\n> really figure it out, so it can't print a nice error message.\n> \n> With the strict prefix convention, the parser can produce excellent\n> error messages.\n> \n\nExcellent error messages aren't good enough. It's ok for Python, since \nthat's a programming language. We can expect infinitely more from \nprogrammers than we can from users.\n\n> It irritates you the first few times until you learn to do it right in \n> first place, just like it irritates most beginning C programmers that the\n> compiler keeps complaining about missing semicolons.\n> \n\nIf I'm trying out some new stuff that annoys me three times without me \nseeing an obvious error on my part (in the editor of my choice) I \nusually write it down as broken and move on.\n\n> Computers will be annoying about syntax until they learn to do what\n> I want them to do rather than what I tell them to do, at which point\n> they'll be smart enough to start being annoying by doing what they want\n> to to instead of what I want them to do.\n> \n\nThat's not the point. If everything looks good it should work good, \nregardless of which editor or tab-setting one's using.\n\n> \n>>Of course, since I believe that tabs are always exactly 8 characters, I'd \n>>also be perfectly happy to just declare that anybody who disagrees with me \n>>is a moron and deserves to die (*).\n> \n> \n> Seriously, you could always have it print warning messages but try to\n> keep going by assuming 8 space tabs so that at least you can postpone\n> fixing the problem until your current train of thought has pulled into\n> the station.\n\n\nThere used to be $TABSIZE (or some such). Check it if you implement \nthis. Or just skip it entirely. I would prefer the latter.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12536","messageId":"20051122132144.24691.qmail@science.horizon.com","threadId":"2644","inReplyTo":"4382D31E.40400@op5.se","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"","fromEmail":"linux@horizon.com","sentAt":"2005-11-22T13:21:44Z","receivedAt":"2005-11-22T13:21:44Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"> So, would this be considered legal or would it barf on baz?\n> \n> foo\t\t# No prefix\n> \tbar\t# tab prefix\n>         baz     # 8 spaces prefix\n\nIt would barf on baz.  \"\\t\" is not a prefix of \"        \".\n\n> Most people have tabsize at 8. Some don't. Some editors insert spaces\n> instead of tabs while others don't. If we just match strings we'll\n> end up with users sending bug-reports by cut'n pasting their perfectly\n> valid-looking config which mixes tabs and spaces just because it's\n> been edited by people using different editors.\n\n> Real fun would be if the mta sends tabs as spaces. Then there'd\n> be no way at all of telling if the config *is* valid or not.\n\nWe have this problem already with whitespace damage in the \"before\"\nparts of patches.  Are you suggesting that the user will be confused\nbecause some third party edited their config using an editor that\nmessed up the leading whitespace and then just left it broken?\n\nThere's a certain level of \"evil gremlins came in during the night and\nadded bugs to my code\" that I bloody well expect to be confusing!\n\nYou might have problems inserting a line that suffers mailer damage,\nmailer sends you, but if you had sent it as a context diff, the patch\nprocess would have choked on the whitespace anyway.\n\nI'm not particularly agitating for an indent-based syntax, but it\nis moderately popular and successful, and anyone criticising it should\nat least know how it works.\n\nThe standard interpretation of leading whitespace accepts basically\nthat subset of \"looks right\" that is insensitive to tab setting.\n\n> Excellent error messages aren't good enough. It's ok for Python, since \n> that's a programming language. We can expect infinitely more from \n> programmers than we can from users.\n\nWe're talking about git users here, right?\nMore specifically, we're talking about git users who are pulling from\nmultiple remote trees, no?\n\nPerhaps you could clarify how this set of people is not a strict\nsubset of the set of programmers...\n\n>> It irritates you the first few times until you learn to do it right in \n>> first place, just like it irritates most beginning C programmers that the\n>> compiler keeps complaining about missing semicolons.\n\n> If I'm trying out some new stuff that annoys me three times without me \n> seeing an obvious error on my part (in the editor of my choice) I \n> usually write it down as broken and move on.\n\nWhat part of something like:\n\tCan't figure out nesting level on line 232.  Its leading\n\twhitespace (\"        \", all spaces), is not a prefix or\n\textension of the whitespace on the preceding line 230\n\t(\"\\t\", all tabs).\nmakes the error non-obvious?\n\nIf you refuse to read the error message at all, you can get confused,\nbut you'll also be confused by perfectly valid code producing diagnostics\nlike \"error: dereferencing pointer to incomplete type\" if you forget to\n#include the right header 200 lines before the location of your error.\n\n>> Computers will be annoying about syntax until they learn to do what\n>> I want them to do rather than what I tell them to do, at which point\n>> they'll be smart enough to start being annoying by doing what they want\n>> to to instead of what I want them to do.\n\n> That's not the point. If everything looks good it should work good, \n> regardless of which editor or tab-setting one's using.\n\nUnfortunately, that's provably impossible, because it will look\ndifferent to different people.\n\nProof by example:\n\nheader1\n    header2\t# 4 spaces\n        body3\t# 8 spaces\n\tbody4\t# one tab\n\nThat looks good to me, with 8-space tabs:\n\nheader1 {\n    header2 {\n        body3\n        body4\n    }\n}\n\nBut it also looks great to someone with 4-space tabs:\n\nheader1 {\n    header2 {\n        body3\n    }\n    body4\n}\n\nToo bad it doesn't work the same.\n\nThe standard whitespace-parsing algorithm rejects \"body4\" on the grounds\nthat it's ambiguous.  Simple, robust, and no making guesses that lead\nto an error message 20 lines beyond the actual problem.  It just says\n\"Hey!  Fix line 4!\"\n\n>> Seriously, you could always have it print warning messages but try to\n>> keep going by assuming 8 space tabs so that at least you can postpone\n>> fixing the problem until your current train of thought has pulled into\n>> the station.\n\n> There used to be $TABSIZE (or some such). Check it if you implement \n> this. Or just skip it entirely. I would prefer the latter.\n\nFine with me.  It's a fallback heuristic anyway.\n"},{"id":"12538","messageId":"438323E9.3050809@op5.se","threadId":"2644","inReplyTo":"20051122132144.24691.qmail@science.horizon.com","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2005-11-22T13:58:01Z","receivedAt":"2005-11-22T13:58:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"linux@horizon.com wrote:\n>>So, would this be considered legal or would it barf on baz?\n>>\n>>foo\t\t# No prefix\n>>\tbar\t# tab prefix\n>>        baz     # 8 spaces prefix\n> \n> \n> It would barf on baz.  \"\\t\" is not a prefix of \"        \".\n> \n\nBut to the human eye they are the same. This is just a backwards way of \nmaking the computer think it's smart by recognizing a difference that, \nfor all human purposes, aren't there. Like Linus said some posts ago; \nsoftware should conform to humans. Not the other way around.\n\n> \n>>Real fun would be if the mta sends tabs as spaces. Then there'd\n>>be no way at all of telling if the config *is* valid or not.\n> \n> \n> We have this problem already with whitespace damage in the \"before\"\n> parts of patches.  Are you suggesting that the user will be confused\n> because some third party edited their config using an editor that\n> messed up the leading whitespace and then just left it broken?\n> \n\nThis is supposed to be edited by git config-set (or at least editable). \nWhen that breaks or when someone finds it inconvenient people will start \nusing their editors. The logical way for a user to align new text to \ntext 8 spaces away is to use the tab key. Depending on the editor (and \nthe settings of that editor), the user will seem to have made perfectly \ncorrect changes that git will barf on, which brings us back to \"software \nshould conform to humans\".\n\nIn short; This proposed format is just one step above a binary-format \nconfig file from the user-friendliness perspective.\n\n\n> There's a certain level of \"evil gremlins came in during the night and\n> added bugs to my code\" that I bloody well expect to be confusing!\n> \n\nCan't help you there. I only do the cuddly mogwais.\n\n> You might have problems inserting a line that suffers mailer damage,\n> mailer sends you, but if you had sent it as a context diff, the patch\n> process would have choked on the whitespace anyway.\n> \n\ngit only does unified diffs (but doesn't allow any fuzz, so it would \nbreak those too).\n\n> I'm not particularly agitating for an indent-based syntax, but it\n> is moderately popular and successful, and anyone criticising it should\n> at least know how it works.\n> \n> The standard interpretation of leading whitespace accepts basically\n> that subset of \"looks right\" that is insensitive to tab setting.\n> \n> \n>>Excellent error messages aren't good enough. It's ok for Python, since \n>>that's a programming language. We can expect infinitely more from \n>>programmers than we can from users.\n> \n> \n> We're talking about git users here, right?\n> More specifically, we're talking about git users who are pulling from\n> multiple remote trees, no?\n> \n> Perhaps you could clarify how this set of people is not a strict\n> subset of the set of programmers...\n> \n\nPackage maintainers, tech-doc writers. Not really suits, but with a hint \nof tie nonetheless.\n\n> \n>>That's not the point. If everything looks good it should work good, \n>>regardless of which editor or tab-setting one's using.\n> \n> \n> Unfortunately, that's provably impossible, because it will look\n> different to different people.\n> \n> Proof by example:\n> \n> header1\n>     header2\t# 4 spaces\n>         body3\t# 8 spaces\n> \tbody4\t# one tab\n> \n> That looks good to me, with 8-space tabs:\n> \n> header1 {\n>     header2 {\n>         body3\n>         body4\n>     }\n> }\n> \n> But it also looks great to someone with 4-space tabs:\n> \n> header1 {\n>     header2 {\n>         body3\n>     }\n>     body4\n> }\n> \n> Too bad it doesn't work the same.\n> \n> The standard whitespace-parsing algorithm rejects \"body4\" on the grounds\n> that it's ambiguous.\n\n\nWhat I conclude from these examples are that;\n1. Any brace-parsing algorithm does the right thing for every case.\n2. Indentation-level parsing doesn't, so it's less robust.\n\nIndentation-level parsing is nice-ish in a programming language because \nit enforces strong typing so others that read your program can easily do \nso. I personally disagree with that, but I can see the point.\n\nHow important is it that others can easily read your configuration file?\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"12557","messageId":"20051122191234.GA9040@puritan.petwork","threadId":"2644","inReplyTo":"4382DFDA.6040306@op5.se","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"Nikolai Weibull","fromEmail":"mailing-lists.git@rawuncut.elitemail.org","sentAt":"2005-11-22T19:12:34Z","receivedAt":"2005-11-22T19:12:34Z","isPatch":false,"sender":{"key":"mailing-lists.git@rawuncut.elitemail.org","avatar":null},"body":"Andreas Ericsson wrote:\n\n> Excellent error messages aren't good enough. It's ok for Python, since\n> that's a programming language. We can expect infinitely more from\n> programmers than we can from users.\n\nA semi-related question: who is the target audience of git?  I get the\nfeeling that most users will be programmers, so that's kind of a\nnon-argument (even though I agree with your standpoint).\n\nFurthermore, does it really matter what format .git/config has now that\nwe have git-config-set?  Shouldn't all access go through that command,\nso that we can change to some other format (YAML, XML, STUPIDABBR) if we\nso desire without breaking anything?\n\nFinally, a plain-text easy-to-edit format is great, and that's a good\nenough argument not to use indentation (as has already been pointed out,\nindentation is not always what it seems).\n\n        nikolai\n\n-- \nNikolai Weibull: now available free of charge at http://bitwi.se/!\nBorn in Chicago, IL USA; currently residing in Gothenburg, Sweden.\nmain(){printf(&linux[\"\\021%six\\012\\0\"],(linux)[\"have\"]+\"fun\"-97);}\n"},{"id":"12562","messageId":"94fc236b0511221213s588c4b11k4ee6d5450f3009c9@mail.gmail.com","threadId":"2644","inReplyTo":"20051122191234.GA9040@puritan.petwork","subject":"Re: Get rid of .git/branches/ and .git/remotes/?","fromName":"Adrien Beau","fromEmail":"adrienbeau@gmail.com","sentAt":"2005-11-22T20:13:01Z","receivedAt":"2005-11-22T20:13:01Z","isPatch":false,"sender":{"key":"adrienbeau@gmail.com","avatar":null},"body":"On 11/22/05, Nikolai Weibull <mailing-lists.git@rawuncut.elitemail.org> wrote:\n>\n> who is the target audience of git?  I get the\n> feeling that most users will be programmers, so that's kind of a\n> non-argument (even though I agree with your standpoint).\n\nIf Git is successful, then there will also be a lot of bleeding-edge\nusers, people who want to be able to:\n\n* Get the latest and greatest (and build it and run it)\n* Browse the repository (with gitk or gitweb)\n* Maybe (very occasionnally) create a simple patch\n\nThis is already the case with CVS, plenty of people know (or are\ninstructed to do) cvs checkout, cvs update, and nothing more. That's\nnot much, but they're CVS users, nevertheless.\n"}]}