{"thread":{"id":"709","subject":"[PATCH] diff-cache path restriction fix.","startedAt":"2005-05-25T00:47:08Z","lastAt":"2005-05-28T07:55:44Z","messageCount":17,"participants":["Junio C Hamano","Linus Torvalds","Russ Allbery","Ingo Molnar","Florian Weimer","Thomas Glanzmann","Matthias Urlichs"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"3902","messageId":"7vu0ksrv1v.fsf@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":null,"subject":"[PATCH] diff-cache path restriction fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-25T00:47:08Z","receivedAt":"2005-05-25T00:47:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It advertises the path restriction in documentation and usage\nstring, but the argument parsing code was not updated and was\ncausing it to refuse to run. One liner fix is here.\n\nSigned-off-by: Junio C Hamano \n---\n# - linus: git-update-cache: allow dot-files\n# + (working tree)\ndiff --git a/diff-cache.c b/diff-cache.c\n--- a/diff-cache.c\n+++ b/diff-cache.c\n@@ -164,7 +164,7 @@ int main(int argc, const char **argv)\n \tint ret;\n \n \tread_cache();\n-\twhile (argc > 2) {\n+\twhile (1 < argc && argv[1][0] == '-') {\n \t\tconst char *arg = argv[1];\n \t\targv++;\n \t\targc--;\n\n\n"},{"id":"3905","messageId":"Pine.LNX.4.58.0505241757280.2307@ppc970.osdl.org","threadId":"709","inReplyTo":"7vu0ksrv1v.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-25T01:00:54Z","receivedAt":"2005-05-25T01:00:54Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 May 2005, Junio C Hamano wrote:\n>\n> It advertises the path restriction in documentation and usage\n> string, but the argument parsing code was not updated and was\n> causing it to refuse to run. One liner fix is here.\n\nNo, it's more broken than that. Look at how it uses \"argv[1]\" for the tree\nSHA1, then does \"argv++\" and then uses \"argv[1]\" (which is a totally\ndifferent argument entirely) for error reporting when the tree SHA1 is bad\n\n> -\twhile (argc > 2) {\n> +\twhile (1 < argc && argv[1][0] == '-') {\n\nBtw, that \"1 < argc\" order is very unintuitive to most humans. Like it or \nnot, people get used to things one way, and have a hard time seeing what \nit means when it's the other way around.\n\nAnd when people have a hard time seeing what it means, you get more bugs.\n\nThis is why it is _not_ better to do \n\n\tif (1 == a)\n\nlike some people teach, even if that protects against the \"single equal\nsign\" bug. There are better ways to protect against that one bug (like\nhaving compiler warnings enabled) that don't make the code less obvious.\n\n\t\tLinus\n"},{"id":"3906","messageId":"7vekbwru6x.fsf@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":"Pine.LNX.4.58.0505241757280.2307@ppc970.osdl.org","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-25T01:05:42Z","receivedAt":"2005-05-25T01:05:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> No, it's more broken than that.\n\nI'll take a look at this later and submit an update, but an OT\npoint I feel I should address.\n\nLT> Btw, that \"1 < argc\" order is very unintuitive to most humans.\n\nYeah? Not to people around where I come from, I do not know\nwhy. It is not done for the assignment confusion avoidance\n\"1==a\".\n\nThe comparison lists things in the ascending order from left to\nright. The fact that 1 comes before argc on that line of code\nvisually makes it obvious that I am talking about argc being\nlarger than one and that is the reason. I'd write (argc < 4)\nnot (4 > argc) for the same reason.\n\n\n"},{"id":"3910","messageId":"Pine.LNX.4.58.0505241814220.2307@ppc970.osdl.org","threadId":"709","inReplyTo":"7vekbwru6x.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-25T01:24:58Z","receivedAt":"2005-05-25T01:24:58Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 May 2005, Junio C Hamano wrote:\n\n> >>>>> \"LT\" == Linus Torvalds writes:\n> \n> LT> No, it's more broken than that.\n> \n> I'll take a look at this later and submit an update, but an OT\n> point I feel I should address.\n\nI checked in the fixed arg parsing already ;)\n\n> The comparison lists things in the ascending order from left to\n> right. The fact that 1 comes before argc on that line of code\n> visually makes it obvious that I am talking about argc being\n> larger than one and that is the reason. I'd write (argc < 4)\n> not (4 > argc) for the same reason.\n\nHmm. According to that logic, \">\" and \">=\" is superfluous.\n\nAlso, what language do you actually speak? Every human language I know\n(admittedly, apart from Finnish they are all related) tends to say things\nlike \"if you have more than four children, you're in trouble\", rather than\nsaying \"if four is less than the number of children you have\".\n\nNotice? People compare something _to_ a number. They don't compare a\nnumber to something. We say \"if more than four\", we don't say \"if four is\nless\".\n\nSadly, I can't get google to match \"1 < x\" and \"x > 1\" (it just considers\nall special characters to be basically whitespace, so \"1 < x\" matches \"1\nx\" and \"1.x\" according to google. Usually google is a good way to get a\nfeel for how common some phrase is, but not on things like this.\n\n\t\tLinus\n"},{"id":"3911","messageId":"7v3bscqdlr.fsf@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":"Pine.LNX.4.58.0505241814220.2307@ppc970.osdl.org","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-25T01:49:20Z","receivedAt":"2005-05-25T01:49:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> I checked in the fixed arg parsing already ;)\n\nThanks.\n\nLT> Hmm. According to that logic, \">\" and \">=\" is superfluous.\n\nYes, I was trained by Paul Eggert (me says that proudly).\n\nPractically speaking, the only time I deliberately used > and >=\nwas when I was doing some dialect of SQL that always wanted\nliteral on fixed side and column on the other; I do not remember\nwhich was which and whose SQL anymore.\n\nOf course I sometimes end up using them when I am trying to\nmatch the style of existing code. However, for that particular\ncomparison in diff-cache, there weren't any other around there\nto match, other than the \"if (argc < 2 || ...)\" after the loop,\nwhich was what I myself wrote so it does not count.\n\nLT> Also, what language do you actually speak?\n\nJapanese.\n\nI have not thought about that kind of relationship between the\nnatural language and if() expression at all, and I am certainly\nnot claiming comparing it the logic way is natural in Japanese.\nI think it probably isn't.\n\nLT> ... Usually google is a good way to get a feel for how\nLT> common some phrase is, but not on things like this.\n\nIf you feel strongly about this, just write it in coding-style\ndocument and I'll follow whatever you tell me while I am coding\nfor this project. Honestly, I do not particularly care how\ncommon that is in the wider world outside.\n\n\n"},{"id":"3912","messageId":"87u0kscaob.fsf@windlord.stanford.edu","threadId":"709","inReplyTo":"7v3bscqdlr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Russ Allbery","fromEmail":"rra@stanford.edu","sentAt":"2005-05-25T02:16:20Z","receivedAt":"2005-05-25T02:16:20Z","isPatch":true,"sender":{"key":"rra@stanford.edu","avatar":null},"body":"Junio C Hamano writes:\n\n> Yes, I was trained by Paul Eggert (me says that proudly).\n\n> Practically speaking, the only time I deliberately used > and >=\n> was when I was doing some dialect of SQL that always wanted\n> literal on fixed side and column on the other; I do not remember\n> which was which and whose SQL anymore.\n\n> Of course I sometimes end up using them when I am trying to\n> match the style of existing code. However, for that particular\n> comparison in diff-cache, there weren't any other around there\n> to match, other than the \"if (argc < 2 || ...)\" after the loop,\n> which was what I myself wrote so it does not count.\n\nMy prior programming experience has taught me to read argv > 1 as an\nassertion about argv, as opposed to 1 < argv, which would be an assertion\nabout 1. In other words, as I code, I'm generally thinking about testing\na variable against some sort of boundary condition (which may or may not\nbe itself variable), and the thing that I'm testing goes first, followed\nby the test. As a result, 1 < argv throws me for a moment, since on first\nread it seems to imply the programmer was expecting the value of 1 to\nchange.\n\n-- \nRuss Allbery (rra@stanford.edu) \n"},{"id":"3914","messageId":"7vfywcox06.fsf@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":"87u0kscaob.fsf@windlord.stanford.edu","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-25T02:33:13Z","receivedAt":"2005-05-25T02:33:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I do not think there is any right or wrong in this discussion,\nso I would not make any more comment on this topic for now.\n\nYour interpretation that \"(a cmp-op b) is an assertion on a\" is\none valid interpretation of a boolean expression. I would\nunderstand it if you say you are used to think of it as an\nassertion about the left hand side. I just do not think of it\nthat way. Rather, to me, \"(a cmp-op b)\" (or an boolean\nexpression in any shape for that matter) as a whole is an\nassertion, and it is simply easier for me if a and b are ordered\nfrom left to right, to visually match ascending order.\n\nBut that is only because I am used to read programs written that\nway. Just like you are used to think of these expressions about\nassertions of the left hand side.\n\n"},{"id":"3915","messageId":"Pine.LNX.4.58.0505242002340.2307@ppc970.osdl.org","threadId":"709","inReplyTo":"7v3bscqdlr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-25T03:04:56Z","receivedAt":"2005-05-25T03:04:56Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 24 May 2005, Junio C Hamano wrote:\n>\n> LT> Also, what language do you actually speak?\n> \n> Japanese.\n\nIt is possible it is cultural. I certainly find it harder to read the \n\"unexpected\" way. \n\nBut maybe it's just me. I also have a _really_ hard time with reading\n\"unless(x)\" (aka \"if (!(x))\"), that perl programmers seem to use. \n\n\t\tLinus\n"},{"id":"3916","messageId":"7vwtpong4s.fsf@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":"Pine.LNX.4.58.0505242002340.2307@ppc970.osdl.org","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-25T03:22:59Z","receivedAt":"2005-05-25T03:22:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> On Tue, 24 May 2005, Junio C Hamano wrote:\n>> \nLT> Also, what language do you actually speak?\n>> \n>> Japanese.\n\nLT> It is possible it is cultural. I certainly find it harder to read the \nLT> \"unexpected\" way. \n\nI doubt it is Japanese vs Western kind of cultural. When I said\n\"people around me\", that set of people did not include a single\nJapanese. I meant people who worked with the person I was\ntrained by to use this style. Cultural, maybe, but that is\nprogramming culture and definitely not natural language culture\nin my case.\n\nHere is a quick and dirty experiment which showed quite an\ninteresting statistics. It counts number of '<' and '>' in the\nprogram text, after stripping out ptr->deref (yes it catches\n#include , but they even out and it also catches\nwhatever is in comments, but this is just a Q&D stats for fun).\nThe percentage is how close the program text is to \"visually\nordered\" style:\n\n $ cat count-compare.perl\n #!/usr/bin/perl -w \n\n for my $filename (@ARGV) {\n open I, '<', $filename;\n my ($lt, $gt) = (0, 0);\n while () {\n s/->//g; # pointer deref not comparison\n $lt += tr//>/; # count\n }\n close I;\n my $ratio = ($lt / ($lt + $gt)) * 100;\n printf \"'<' (%d) '>' (%d) (%d%%) %s\\n\", $lt, $gt, $ratio, $filename;\n }\n $ perl count-compare.perl diff*.c\n '<' (9) '>' (4) (69%) diff-cache.c\n '<' (20) '>' (26) (43%) diff-delta.c\n '<' (8) '>' (1) (88%) diff-files.c\n '<' (12) '>' (1) (92%) diff-helper.c\n '<' (11) '>' (11) (50%) diff-tree.c\n '<' (28) '>' (10) (73%) diff.c\n '<' (3) '>' (0) (100%) diffcore-pathspec.c\n '<' (2) '>' (0) (100%) diffcore-pickaxe.c\n '<' (22) '>' (6) (78%) diffcore-rename.c\n\nThis clearly shows that diff-delta.c does not have my code at\nall. Most of the others have been touched moderately to heavily\nby me, or in some cases done entirely by me.\n\nPersonally, what I find most interesting is that diff-tree.c is\nsomething you did quite a lot of nice features (and hence\nsomething I was afraid to touch), and the number clearly shows\nmy hesitation. It does not have as many '<' as it would have\nhad, if I had mucked with it as freely as I did to the others.\n\n"},{"id":"3922","messageId":"20050525083143.GA27025@elte.hu","threadId":"709","inReplyTo":"Pine.LNX.4.58.0505241814220.2307@ppc970.osdl.org","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-25T08:31:43Z","receivedAt":"2005-05-25T08:31:43Z","isPatch":true,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> Hmm. According to that logic, \">\" and \">=\" is superfluous.\n> \n> Also, what language do you actually speak? Every human language I know \n> (admittedly, apart from Finnish they are all related) tends to say \n> things like \"if you have more than four children, you're in trouble\", \n> rather than saying \"if four is less than the number of children you \n> have\".\n\n[ add Hungarian to that short list - there it's a pretty natural thing \nto say \"if four is less than the number of ...\" in everyday life :-| \nInterestingly, having an insanely complex wacko weird language helps \nkids learn abstraction early, and results in an unusually high per \ncapita proportion of scientists. If China adopted Finnish as a second \nlanguage the global domination of the US would be history in 50 years\n;-) ]\n\n\tIngo\n"},{"id":"3923","messageId":"20050525090616.GB27025@elte.hu","threadId":"709","inReplyTo":"Pine.LNX.4.58.0505242002340.2307@ppc970.osdl.org","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Ingo Molnar","fromEmail":"mingo@elte.hu","sentAt":"2005-05-25T09:06:16Z","receivedAt":"2005-05-25T09:06:16Z","isPatch":true,"sender":{"key":"mingo@elte.hu","avatar":null},"body":"\n* Linus Torvalds wrote:\n\n> On Tue, 24 May 2005, Junio C Hamano wrote:\n> >\n> > LT> Also, what language do you actually speak?\n> > \n> > Japanese.\n> \n> It is possible it is cultural. I certainly find it harder to read the \n> \"unexpected\" way.\n\ni'm quite sure it's related to ambiguity. The main problem for the human \nbrain when reading code is ambiguity of expression - ambiguity triggers \n'logic' areas of the brain, instead of the 'visual automation' portions\nof the brain. Like it or not, most of the code reading we do is all\nautomatism, if we had to _think_ about the visual structure of the code\nwe'd be much less effective.\n\nThe moment we fall out of automation (you go to the bathroom in the \nmorning but the toothpaste is empty, or you are in the shop and the \ncoffee area got moved to another place), we feel unease. Thinking during \nnormally routine activities means problems, it means distraction, it \nmeant larger reaction times in the jungle for millions of years, and \nthat's why the built-in unease. Thinking generates unease _especially_ \nif you dont expect it and dont want it - even if you happen to be Albert \nEinstein or Linus Torvalds ;) [And it's way too easy to let the \nautopilot drive all the time - there are people who stop thinking in \ntheir childhood and autopilot through life.]\n\nCoding styles are mostly there to reduce the syntactic ambiguities of \ncomputer languages (and hence reducing parsing complexity), and thus to \nmake it easier for the human brain to parse them - and thus to give more \nbrain capacity for the real thinking.\n\nthe other interesting question is, why do most coders pick the 'x < 1' \nvariant? I'm quite sure that's due to most of us having learned coding \nvia operators. It's \"x := 1\" and \"x /= 2\", where the mirror image is not \nvalid - and we extend that expectation to ambiguous operators too. It's \nthe more complex entitity (the variable) that we think about first, and \nthen comes the less complex entity. But if someone has a strong math \nbackground (Junio?) then the \"1 < x < 5\" syntax could be the natural \nthing he got used to.\n\nso as long as the actual expressions are used in an unambiguous way, \nit's fine and it's part of the coding style and it's all a matter of \ngetting used to it. Junio's method is just as unambiguous. How quickly\nyou can adopt to another coding style is directly related to how\npracticed you are at it, but it also depends on your fundamental\nabstraction abilities. The overwhelming majority of coders dont \"switch\"\na coding style that easily, but e.g. people who maintain a large number\nof packages or use lots of languages are very good at it. You have the\nluxory to be able to read your own coding style all day so it's pretty\nnatural to feel unease if something else comes along :)\n\n\tIngo\n"},{"id":"3933","messageId":"8764x7i99t.fsf@deneb.enyo.de","threadId":"709","inReplyTo":"7vekbwru6x.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2005-05-25T16:02:22Z","receivedAt":"2005-05-25T16:02:22Z","isPatch":true,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Junio C. Hamano:\n\n> LT> Btw, that \"1 < argc\" order is very unintuitive to most humans.\n>\n> Yeah? Not to people around where I come from, I do not know\n> why. It is not done for the assignment confusion avoidance\n> \"1==a\".\n\nIn a comparison, it's common to mention the most-varying part first.\nIf you do this consistently, it increases readability.\n"},{"id":"3934","messageId":"Pine.LNX.4.58.0505250948340.2307@ppc970.osdl.org","threadId":"709","inReplyTo":"20050525090616.GB27025@elte.hu","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-05-25T17:07:21Z","receivedAt":"2005-05-25T17:07:21Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 25 May 2005, Ingo Molnar wrote:\n>\n> Like it or not, most of the code reading we do is all automatism, if we\n> had to _think_ about the visual structure of the code we'd be much less\n> effective.\n\nAbsolutely. And you _should_ like it, because it means that you can \nconcentrate on the big problems.\n\nI suspect I react more strongly to some coding style issues than most, \nexactly because I've been so involved with just one language and one style \nfor so long that I've got more of an auto-pilot than most: normally my \nbrain just coasts past 99% of all code, without having to be very \nconscious about it at all, exactly because the patterns have become so \ningrained.\n\nIn contrast, somebody who works on different projects and with many\ndifferent languages is likely to have many more patterns, but they are\nprobably less deep, so breaking them isn't as disturbing.\n\n> But if someone has a strong math background (Junio?) then\n> the \"1 < x < 5\" syntax could be the natural thing he got used to.\n\nActually, even in math (in fact, very _much_ in math) I'd say that people\nalways aim to put the variable on the left side, and you very much tend to\ntry to aim for canonical formats (sort by exponent and variable name). \nYou'd never see anybody write \"y + x = 5\" or \"x + x^2\", because there's a \ncanonical format for it, and people use it.\n\nThe \"1 < x < 5\" syntax is very much the odd man out, and that order for\nthe first part is _only_ used for two-sided comparisons afaik. Math people\n(at least all math texts I've ever seen, and I had math as a strong minor\nalthough admittedly that is some time ago) will invariably write the\nvariable on the left side if there's just one comparison.\n\nIn fact, in math, I'd expect a person to often tend to take the canonical\nformat even further, and sort _everything_ to the left side, and aim to\nleave the right side totally empty (ie \"0\"), exactly because that makes\ncertain combinations much easier. So it wouldn't surprise me at all to see\na math person change \"x > 1\" into \"x - 1 > 0\", but it _would_ surprise me\nto see a math person change it into \"1 < x\" unless it is to combine it\nwith _another_ comparison with \"x\".\n\n\t\t\t\tLinus\n"},{"id":"3943","messageId":"7vpsvfktiw.fsf@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":"20050525090616.GB27025@elte.hu","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-25T19:14:15Z","receivedAt":"2005-05-25T19:14:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"IM\" == Ingo Molnar writes:\n\nIM> ... But if someone has a strong math \nIM> background (Junio?) then the \"1 < x < 5\" syntax could be the natural \nIM> thing he got used to.\n\nI was trained by somebody with a strong math background, but I\nsuspect he insisted that ordering not from math reasons. The\nreason given to me was \"visual ordering\".\n\nI suck at math myself. I even get confused when people do\n\n return !!some_function();\n\n"},{"id":"3945","messageId":"20050525191721.GC22213@cip.informatik.uni-erlangen.de","threadId":"709","inReplyTo":"7vpsvfktiw.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Thomas Glanzmann","fromEmail":"sithglan@stud.uni-erlangen.de","sentAt":"2005-05-25T19:17:21Z","receivedAt":"2005-05-25T19:17:21Z","isPatch":true,"sender":{"key":"sithglan@stud.uni-erlangen.de","avatar":null},"body":"Hello,\n\n> return !!some_function();\n\nI actually wanted to send a diff to get rid of this thing from\nsha_file.c :-)\n\n\tThomas\n"},{"id":"3950","messageId":"pan.2005.05.25.20.31.31.129474@smurf.noris.de","threadId":"709","inReplyTo":"20050525090616.GB27025@elte.hu","subject":"Re: [PATCH] diff-cache path restriction fix.","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-05-25T20:31:31Z","receivedAt":"2005-05-25T20:31:31Z","isPatch":true,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Ingo Molnar wrote:\n\n> But if someone has a strong math background\n> (Junio?) then the \"1 < x < 5\" syntax could be the natural thing he got\n> used to.\n\nOr Python -- and I assume there are more languages where this idiom works\ncorrectly.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\n\n\n"},{"id":"4125","messageId":"7vfyw7yebj.fsf_-_@assigned-by-dhcp.cox.net","threadId":"709","inReplyTo":"7v3bscqdlr.fsf@assigned-by-dhcp.cox.net","subject":"[OT] if (4 < number_of_children) you're in trouble","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-28T07:55:44Z","receivedAt":"2005-05-28T07:55:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I received this from my mentor tonight. Although I said I am\nnot going to discuss this issue anymore, with his permission, I\nwould like to share where the \"visual order\" came from with the\nlist.\n\nFrom: Paul Eggert \nSubject: Re: FYI: comparison order in boolean expressions\nTo: Junio C Hamano \nDate: Sat, 28 May 2005 00:28:31 -0700\n\n> http://marc.theaimsgroup.com/?l=git&m=111698274620068&w=2\n\nThanks! That made my day.\n\nYou can forward the following to that mailing list if you like:\n\n\nI learned the \"textual order should reflect actual order\" convention\nfrom D. Val Schorre, one of the best programmers I've ever worked\nwith. Val was credited by Donald E. Knuth as the first person to\nseriously advocate goto-less programming. In 1974 Knuth wrote:\n\n When I met Schorre in 1963, he told me of his radical ideas, and I\n didn't believe they would work.... In 1964 I challenged him to\n write a program for the eight-queens problem without using go to\n statements, and he responded with a program using recursive\n procedures and Boolean variables, very much like the program later\n published independently by Wirth.\n\n I was still not convinced....\n\nKnuth's reaction to Schorre's ideas on avoiding gotos sounds a bit\nlike Linus's reaction to Schorre's ideas on comparison order, no?\n\nAnyway, here's the reference, if you'd like to find out how Knuth's\nstory ends:\n\n Donald E. Knuth\n Structured Programming with go to Statements\n ACM Computing Surveys 6, 4 (December 1974), 261-301.\n http://portal.acm.org/citation.cfm?id=356640\n\n\nPS. The idea that textual form should reflect the underlying reality\ngoes all the way back to Gottfried Leibniz's alphabet of human thought\n. Leibniz was\na brilliant designer of notations -- one of the best the world has\never seen -- and it is amusing to speculate what he would have done\nwith programming had he been born some time in the past few decades.\n(Personally I suspect that Leibniz would have liked \"1 < x\".)\n\n\n\n\n\n"}]}