{"thread":{"id":"34970","subject":"Re: re[4]: sparse checkout file with windows line endings doesn't work","startedAt":"2013-09-20T01:15:28Z","lastAt":"2013-09-20T18:06:24Z","messageCount":8,"participants":["Duy Nguyen","Martin Gregory","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"227911","messageId":"CACsJy8BeT7ZP+ZQah7FR6ogqRNiiDZYP5SEs8J6J=+gEHU5MUg@mail.gmail.com","threadId":"34970","inReplyTo":"SDZYRFhOTCk2PDAuPVQvMjI4MjE1ODkw@IBMLT4","subject":"Re: re[4]: sparse checkout file with windows line endings doesn't work","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-09-20T01:15:28Z","receivedAt":"2013-09-20T01:15:28Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Sep 20, 2013 at 7:01 AM, Martin Gregory\n<marting@adelaideinterim.com.au> wrote:\n> Hi Duy ,\n>\n> re: [file created in gitbash]\n>\n>>>  Thanks. Please send me the file created by windows shell. I suspected\n>>>  that windows shell may save it in some funny encoding like utf-16..\n>\n>\n> Strangely, I had sent the file created by the windows shell ahead of the one\n> created by gitbash, but here it is again :)\n\nSorry I must have missed it. Anyway there is a trailing space at the\nend of the rule. This is the content of your sparse checkout file in C\nsyntax\n\n\"/CONFIGURATION\\x20\\r\\n\"\n\nMaybe we could warn about trailing spaces.. Stripping them\nautomatically is a possibility, but we need an escape hatch for\n(crazy?) people who actually have trailing spaces in there paths.\n-- \nDuy\n"},{"id":"227913","messageId":"SDZYTDk4NyMxKC4hPVQvMjM1MDUxNjg3@IBMLT4","threadId":"34970","inReplyTo":"CACsJy8BeT7ZP+ZQah7FR6ogqRNiiDZYP5SEs8J6J=+gEHU5MUg@mail.gmail.com","subject":"re[6]: sparse checkout file with windows line endings doesn't work","fromName":"Martin Gregory","fromEmail":"marting@adelaideinterim.com.au","sentAt":"2013-09-20T01:52:01Z","receivedAt":"2013-09-20T01:52:01Z","isPatch":false,"sender":{"key":"marting@adelaideinterim.com.au","avatar":null},"body":"Thanks Duy for the fast response.\n\n> Anyway there is a trailing space at the\n>>  end of the rule. This is the content of your sparse checkout file in C\n>>  syntax\n>>\n>>  \"/CONFIGURATION\\x20\\r\\n\"\n>>\n>>  Maybe we could warn about trailing spaces.. Stripping them\n>>  automatically is a possibility, but we need an escape hatch for\n>>  (crazy?) people who actually have trailing spaces in there paths.\n\nYuk eh?\n\nI just discovered that if you do\n\necho /CONFIGURATION      > .git\\info\\sparse-checkout\n\nin Windows, you get 5 training spaces!\n\nMan, I hate Windows!\n\nSomething that would help is an easier way to debug sparse-checkout rules.\n\nWhen something goes wrong, there appears to be no way to understand what\ngit thinks it's reading.   I'm not sure if such a way, if it existed, would help with\ntrailing spaces, but if you could say\n\ngit read-tree -muv HEAD\n\nand it would say\n\nreading '.git\\info\\sparse-checkout'...\nrule '/CONFIGURATION ' - no matches\n\nthat would solve actually two problems:\n\n1) You can see that it thinks there is a space there\n\n2) the config file name is sparse-checkout, with a dash, not sparsecheckout...\na mistake I made that had me scratching my head for some time, since everywhere\nelse it doesn't have a dash!\n\nThanks again for your quick help.\n\nMartin\n"},{"id":"227914","messageId":"CACsJy8AzrSPqcXhcLV_q6J-+qZaQMPFfO6eq6C=HvdvcXw+eSw@mail.gmail.com","threadId":"34970","inReplyTo":"SDZYTDk4NyMxKC4hPVQvMjM1MDUxNjg3@IBMLT4","subject":"Re: re[6]: sparse checkout file with windows line endings doesn't work","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-09-20T02:28:39Z","receivedAt":"2013-09-20T02:28:39Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Sep 20, 2013 at 8:52 AM, Martin Gregory\n<marting@adelaideinterim.com.au> wrote:\n> Something that would help is an easier way to debug sparse-checkout rules.\n>\n> When something goes wrong, there appears to be no way to understand what\n> git thinks it's reading.   I'm not sure if such a way, if it existed, would help with\n> trailing spaces, but if you could say\n>\n> git read-tree -muv HEAD\n>\n> and it would say\n>\n> reading '.git\\info\\sparse-checkout'...\n> rule '/CONFIGURATION ' - no matches\n>\n> that would solve actually two problems:\n>\n> 1) You can see that it thinks there is a space there\n>\n> 2) the config file name is sparse-checkout, with a dash, not sparsecheckout...\n> a mistake I made that had me scratching my head for some time, since everywhere\n> else it doesn't have a dash!\n\n\"git check-ignore\" is the closet one to this. Remember sparse-checkout\nand .gitignore share the same syntax, you could feed sparse-checkout\nfile to check-ignore. You (or somebody else) may need to improve\ncheck-ignore a bit, though, to show the quotes because I don't think\nit does now.\n-- \nDuy\n"},{"id":"227919","messageId":"20130920031705.GA15101@sigill.intra.peff.net","threadId":"34970","inReplyTo":"SDZYTDk4NyMxKC4hPVQvMjM1MDUxNjg3@IBMLT4","subject":"Re: sparse checkout file with windows line endings doesn't work","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-20T03:17:05Z","receivedAt":"2013-09-20T03:17:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:\n\n> When something goes wrong, there appears to be no way to understand what\n> git thinks it's reading.   I'm not sure if such a way, if it existed, would help with\n> trailing spaces, but if you could say\n> \n> git read-tree -muv HEAD\n> \n> and it would say\n> \n> reading '.git\\info\\sparse-checkout'...\n> rule '/CONFIGURATION ' - no matches\n\nI don't think you can do that in the general case of read-tree. You may\nhave sparse paths that exist in some commits, but not others. As you\nmove around in history, a sparse entry that does not match might do so\nbecause it is poorly written, or it might do so because you just don't\nhappen to have any matching paths in the commit you are moving to. The\nformer is a problem, but warning on the latter would be useless noise.\n\n-Peff\n"},{"id":"227921","messageId":"SDZYUVdaTCUzXD8wPVQvMjQwMzM4MTcx@IBMLT4","threadId":"34970","inReplyTo":"20130920031705.GA15101@sigill.intra.peff.net","subject":"re[2]: sparse checkout file with windows line endings doesn't work","fromName":"Martin Gregory","fromEmail":"marting@adelaideinterim.com.au","sentAt":"2013-09-20T03:24:45Z","receivedAt":"2013-09-20T03:24:45Z","isPatch":false,"sender":{"key":"marting@adelaideinterim.com.au","avatar":null},"body":">>  On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:\n>>\n>>  > When something goes wrong, there appears to be no way to understand what\n>>  > git thinks it's reading. I'm not sure if such a way, if it existed,\n>>  would help with\n>>  > trailing spaces, but if you could say\n>>  >\n>>  > git read-tree -muv HEAD\n>>  >\n>>  > and it would say\n>>  >\n>>  > reading '.git\\info\\sparse-checkout'...\n>>  > rule '/CONFIGURATION ' - no matches\n>>\n>>  I don't think you can do that in the general case of read-tree. You may\n>>  have sparse paths that exist in some commits, but not others. As you\n>>  move around in history, a sparse entry that does not match might do so\n>>  because it is poorly written, or it might do so because you just don't\n>>  happen to have any matching paths in the commit you are moving to. The\n>>  former is a problem, but warning on the latter would be useless noise.\n\nEven if you only do it as part of a verbose option?\n\nMy thinking was that when you specify verbose, you are saying \"I don't\nmind a bit of noise in order to find what I'mlooking for\".\n\nTherfore, if you have a \"no match\" on a valid but not-in-view in the commit,\nit's not a \"problem\", it's just part of the verbose information...\n\nRegards,\n\nMartin\n\n\n--\nMartin Gregory\nSenior Consultant, Adelaide Interim\nP:   +61 8 7200 5350\nM:   +61 402 410 971\nF:   +61 8 7200 3725\n"},{"id":"227923","messageId":"20130920033821.GD15101@sigill.intra.peff.net","threadId":"34970","inReplyTo":"SDZYUVdaTCUzXD8wPVQvMjQwMzM4MTcx@IBMLT4","subject":"Re: sparse checkout file with windows line endings doesn't work","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-09-20T03:38:21Z","receivedAt":"2013-09-20T03:38:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Sep 20, 2013 at 12:54:45PM +0930, Martin Gregory wrote:\n\n> >>  I don't think you can do that in the general case of read-tree. You may\n> >>  have sparse paths that exist in some commits, but not others. As you\n> >>  move around in history, a sparse entry that does not match might do so\n> >>  because it is poorly written, or it might do so because you just don't\n> >>  happen to have any matching paths in the commit you are moving to. The\n> >>  former is a problem, but warning on the latter would be useless noise.\n> \n> Even if you only do it as part of a verbose option?\n> \n> My thinking was that when you specify verbose, you are saying \"I don't\n> mind a bit of noise in order to find what I'mlooking for\".\n\nI don't mind a special option to turn this on for debugging, but the\nnormal \"-v\" for read-tree is not \"show me random noise\", but rather\n\"keep me occupied with a progress bar\". If it were triggered by two or\nmore \"-v\" options (which could also contain other debugging output), I'd\nbe more sympathetic.\n\n-Peff\n"},{"id":"227924","messageId":"SDZYU1EwTCM8XlI0PVQvMjQyMDIzNzAz@IBMLT4","threadId":"34970","inReplyTo":"20130920033821.GD15101@sigill.intra.peff.net","subject":"re[2]: sparse checkout file with windows line endings doesn't work","fromName":"Martin Gregory","fromEmail":"marting@adelaideinterim.com.au","sentAt":"2013-09-20T03:52:58Z","receivedAt":"2013-09-20T03:52:58Z","isPatch":false,"sender":{"key":"marting@adelaideinterim.com.au","avatar":null},"body":">>  I don't mind a special option to turn this on for debugging, but the\n>>  normal \"-v\" for read-tree is not \"show me random noise\", but rather\n>>  \"keep me occupied with a progress bar\". If it were triggered by two or\n>>  more \"-v\" options (which could also contain other debugging output), I'd\n>>  be more sympathetic.\n\nRight totally - sorry, I'm not familiar with what -v would normally do (! I better get!)\n\nMy suggestion is more along the lines of \"it would be really helpful to have a really\nverbose debugging option for sparsecheckout (be that read-tree or something else),\nbecause it can be quite hard to work out why it's not working the way you expect'.\n\nRegards,\n\nMartin\n"},{"id":"227940","messageId":"xmqqa9j7qsf3.fsf@gitster.dls.corp.google.com","threadId":"34970","inReplyTo":"20130920031705.GA15101@sigill.intra.peff.net","subject":"Re: sparse checkout file with windows line endings doesn't work","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-09-20T18:06:24Z","receivedAt":"2013-09-20T18:06:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:\n>\n>> When something goes wrong, there appears to be no way to understand what\n>> git thinks it's reading.   I'm not sure if such a way, if it existed, would help with\n>> trailing spaces, but if you could say\n>> \n>> git read-tree -muv HEAD\n>> \n>> and it would say\n>> \n>> reading '.git\\info\\sparse-checkout'...\n>> rule '/CONFIGURATION ' - no matches\n>\n> I don't think you can do that in the general case of read-tree. You may\n> have sparse paths that exist in some commits, but not others. As you\n> move around in history, a sparse entry that does not match might do so\n> because it is poorly written, or it might do so because you just don't\n> happen to have any matching paths in the commit you are moving to. The\n> former is a problem, but warning on the latter would be useless noise.\n\nWhile that is very true, if\n\n (1) there is a good criterion to tell that a path pattern in sparse\n     file is very likely to be a mistake; and\n\n (2) we can guess uniquely what likely-to-be-intended path pattern\n     the above is a typo for\n\nit may be reasonable to allow people to do:\n\n    GIT_PATH_PATTERN_DEBUG=yes git read-tree -m -u HEAD\n\nand get a diagnostic message\n\n\tA rule '/CONFIGURATION ' does not match, but would have\n\tmatched a path if it were spelled '/CONFIGURATION'\n\nor something like that.  The same applies for exclude and possibly\nattribute.\n\nNot my itch, though.  Both of these preconditions are *hard*;\nlimiting only to trailing whitespaces would be an easy start, but\nthat limitation would make things pretty much useless on sane\nplatforms.\n"}]}