# Re: re[4]: sparse checkout file with windows line endings doesn't work 8 messages from 2013-09-20 to 2013-09-20. Participants: Duy Nguyen, Martin Gregory, Jeff King, Junio C Hamano. Thread: https://gitlist.dev/t/34970 ## Duy Nguyen, 2013-09-20 01:15 Subject: Re: re[4]: sparse checkout file with windows line endings doesn't work Message-ID: URL: https://gitlist.dev/e/CACsJy8BeT7ZP%2BZQah7FR6ogqRNiiDZYP5SEs8J6J%3D%2BgEHU5MUg%40mail.gmail.com In-Reply-To: ``` On Fri, Sep 20, 2013 at 7:01 AM, Martin Gregory wrote: > Hi Duy , > > re: [file created in gitbash] > >>> Thanks. Please send me the file created by windows shell. I suspected >>> that windows shell may save it in some funny encoding like utf-16.. > > > Strangely, I had sent the file created by the windows shell ahead of the one > created by gitbash, but here it is again :) Sorry I must have missed it. Anyway there is a trailing space at the end of the rule. This is the content of your sparse checkout file in C syntax "/CONFIGURATION\x20\r\n" Maybe we could warn about trailing spaces.. Stripping them automatically is a possibility, but we need an escape hatch for (crazy?) people who actually have trailing spaces in there paths. -- Duy ``` ## Martin Gregory, 2013-09-20 01:52 Subject: re[6]: sparse checkout file with windows line endings doesn't work Message-ID: URL: https://gitlist.dev/e/SDZYTDk4NyMxKC4hPVQvMjM1MDUxNjg3%40IBMLT4 In-Reply-To: ``` Thanks Duy for the fast response. > Anyway there is a trailing space at the >> end of the rule. This is the content of your sparse checkout file in C >> syntax >> >> "/CONFIGURATION\x20\r\n" >> >> Maybe we could warn about trailing spaces.. Stripping them >> automatically is a possibility, but we need an escape hatch for >> (crazy?) people who actually have trailing spaces in there paths. Yuk eh? I just discovered that if you do echo /CONFIGURATION > .git\info\sparse-checkout in Windows, you get 5 training spaces! Man, I hate Windows! Something that would help is an easier way to debug sparse-checkout rules. When something goes wrong, there appears to be no way to understand what git thinks it's reading. I'm not sure if such a way, if it existed, would help with trailing spaces, but if you could say git read-tree -muv HEAD and it would say reading '.git\info\sparse-checkout'... rule '/CONFIGURATION ' - no matches that would solve actually two problems: 1) You can see that it thinks there is a space there 2) the config file name is sparse-checkout, with a dash, not sparsecheckout... a mistake I made that had me scratching my head for some time, since everywhere else it doesn't have a dash! Thanks again for your quick help. Martin ``` ## Duy Nguyen, 2013-09-20 02:28 Subject: Re: re[6]: sparse checkout file with windows line endings doesn't work Message-ID: URL: https://gitlist.dev/e/CACsJy8AzrSPqcXhcLV_q6J-%2BqZaQMPFfO6eq6C%3DHvdvcXw%2BeSw%40mail.gmail.com In-Reply-To: ``` On Fri, Sep 20, 2013 at 8:52 AM, Martin Gregory wrote: > Something that would help is an easier way to debug sparse-checkout rules. > > When something goes wrong, there appears to be no way to understand what > git thinks it's reading. I'm not sure if such a way, if it existed, would help with > trailing spaces, but if you could say > > git read-tree -muv HEAD > > and it would say > > reading '.git\info\sparse-checkout'... > rule '/CONFIGURATION ' - no matches > > that would solve actually two problems: > > 1) You can see that it thinks there is a space there > > 2) the config file name is sparse-checkout, with a dash, not sparsecheckout... > a mistake I made that had me scratching my head for some time, since everywhere > else it doesn't have a dash! "git check-ignore" is the closet one to this. Remember sparse-checkout and .gitignore share the same syntax, you could feed sparse-checkout file to check-ignore. You (or somebody else) may need to improve check-ignore a bit, though, to show the quotes because I don't think it does now. -- Duy ``` ## Jeff King, 2013-09-20 03:17 Subject: Re: sparse checkout file with windows line endings doesn't work Message-ID: <20130920031705.GA15101@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130920031705.GA15101%40sigill.intra.peff.net In-Reply-To: ``` On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote: > When something goes wrong, there appears to be no way to understand what > git thinks it's reading. I'm not sure if such a way, if it existed, would help with > trailing spaces, but if you could say > > git read-tree -muv HEAD > > and it would say > > reading '.git\info\sparse-checkout'... > rule '/CONFIGURATION ' - no matches I don't think you can do that in the general case of read-tree. You may have sparse paths that exist in some commits, but not others. As you move around in history, a sparse entry that does not match might do so because it is poorly written, or it might do so because you just don't happen to have any matching paths in the commit you are moving to. The former is a problem, but warning on the latter would be useless noise. -Peff ``` ## Martin Gregory, 2013-09-20 03:24 Subject: re[2]: sparse checkout file with windows line endings doesn't work Message-ID: URL: https://gitlist.dev/e/SDZYUVdaTCUzXD8wPVQvMjQwMzM4MTcx%40IBMLT4 In-Reply-To: <20130920031705.GA15101@sigill.intra.peff.net> ``` >> On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote: >> >> > When something goes wrong, there appears to be no way to understand what >> > git thinks it's reading. I'm not sure if such a way, if it existed, >> would help with >> > trailing spaces, but if you could say >> > >> > git read-tree -muv HEAD >> > >> > and it would say >> > >> > reading '.git\info\sparse-checkout'... >> > rule '/CONFIGURATION ' - no matches >> >> I don't think you can do that in the general case of read-tree. You may >> have sparse paths that exist in some commits, but not others. As you >> move around in history, a sparse entry that does not match might do so >> because it is poorly written, or it might do so because you just don't >> happen to have any matching paths in the commit you are moving to. The >> former is a problem, but warning on the latter would be useless noise. Even if you only do it as part of a verbose option? My thinking was that when you specify verbose, you are saying "I don't mind a bit of noise in order to find what I'mlooking for". Therfore, if you have a "no match" on a valid but not-in-view in the commit, it's not a "problem", it's just part of the verbose information... Regards, Martin -- Martin Gregory Senior Consultant, Adelaide Interim P: +61 8 7200 5350 M: +61 402 410 971 F: +61 8 7200 3725 ``` ## Jeff King, 2013-09-20 03:38 Subject: Re: sparse checkout file with windows line endings doesn't work Message-ID: <20130920033821.GD15101@sigill.intra.peff.net> URL: https://gitlist.dev/e/20130920033821.GD15101%40sigill.intra.peff.net In-Reply-To: ``` On Fri, Sep 20, 2013 at 12:54:45PM +0930, Martin Gregory wrote: > >> I don't think you can do that in the general case of read-tree. You may > >> have sparse paths that exist in some commits, but not others. As you > >> move around in history, a sparse entry that does not match might do so > >> because it is poorly written, or it might do so because you just don't > >> happen to have any matching paths in the commit you are moving to. The > >> former is a problem, but warning on the latter would be useless noise. > > Even if you only do it as part of a verbose option? > > My thinking was that when you specify verbose, you are saying "I don't > mind a bit of noise in order to find what I'mlooking for". I don't mind a special option to turn this on for debugging, but the normal "-v" for read-tree is not "show me random noise", but rather "keep me occupied with a progress bar". If it were triggered by two or more "-v" options (which could also contain other debugging output), I'd be more sympathetic. -Peff ``` ## Martin Gregory, 2013-09-20 03:52 Subject: re[2]: sparse checkout file with windows line endings doesn't work Message-ID: URL: https://gitlist.dev/e/SDZYU1EwTCM8XlI0PVQvMjQyMDIzNzAz%40IBMLT4 In-Reply-To: <20130920033821.GD15101@sigill.intra.peff.net> ``` >> I don't mind a special option to turn this on for debugging, but the >> normal "-v" for read-tree is not "show me random noise", but rather >> "keep me occupied with a progress bar". If it were triggered by two or >> more "-v" options (which could also contain other debugging output), I'd >> be more sympathetic. Right totally - sorry, I'm not familiar with what -v would normally do (! I better get!) My suggestion is more along the lines of "it would be really helpful to have a really verbose debugging option for sparsecheckout (be that read-tree or something else), because it can be quite hard to work out why it's not working the way you expect'. Regards, Martin ``` ## Junio C Hamano, 2013-09-20 18:06 Subject: Re: sparse checkout file with windows line endings doesn't work Message-ID: URL: https://gitlist.dev/e/xmqqa9j7qsf3.fsf%40gitster.dls.corp.google.com In-Reply-To: <20130920031705.GA15101@sigill.intra.peff.net> ``` Jeff King writes: > On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote: > >> When something goes wrong, there appears to be no way to understand what >> git thinks it's reading. I'm not sure if such a way, if it existed, would help with >> trailing spaces, but if you could say >> >> git read-tree -muv HEAD >> >> and it would say >> >> reading '.git\info\sparse-checkout'... >> rule '/CONFIGURATION ' - no matches > > I don't think you can do that in the general case of read-tree. You may > have sparse paths that exist in some commits, but not others. As you > move around in history, a sparse entry that does not match might do so > because it is poorly written, or it might do so because you just don't > happen to have any matching paths in the commit you are moving to. The > former is a problem, but warning on the latter would be useless noise. While that is very true, if (1) there is a good criterion to tell that a path pattern in sparse file is very likely to be a mistake; and (2) we can guess uniquely what likely-to-be-intended path pattern the above is a typo for it may be reasonable to allow people to do: GIT_PATH_PATTERN_DEBUG=yes git read-tree -m -u HEAD and get a diagnostic message A rule '/CONFIGURATION ' does not match, but would have matched a path if it were spelled '/CONFIGURATION' or something like that. The same applies for exclude and possibly attribute. Not my itch, though. Both of these preconditions are *hard*; limiting only to trailing whitespaces would be an easy start, but that limitation would make things pretty much useless on sane platforms. ```