* Re: re[4]: sparse checkout file with windows line endings doesn't work [not found] ` <SDZYRFhOTCk2PDAuPVQvMjI4MjE1ODkw@IBMLT4> @ 2013-09-20 1:15 ` Duy Nguyen 2013-09-20 1:52 ` re[6]: " Martin Gregory 0 siblings, 1 reply; 10+ messages in thread From: Duy Nguyen @ 2013-09-20 1:15 UTC (permalink / raw) To: Martin Gregory; +Cc: Git Mailing List On Fri, Sep 20, 2013 at 7:01 AM, Martin Gregory <marting@adelaideinterim.com.au> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* re[6]: sparse checkout file with windows line endings doesn't work 2013-09-20 1:15 ` re[4]: sparse checkout file with windows line endings doesn't work Duy Nguyen @ 2013-09-20 1:52 ` Martin Gregory 2013-09-20 2:28 ` Duy Nguyen 2013-09-20 3:17 ` Jeff King 0 siblings, 2 replies; 10+ messages in thread From: Martin Gregory @ 2013-09-20 1:52 UTC (permalink / raw) To: Duy Nguyen, Martin Gregory; +Cc: Git Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: re[6]: sparse checkout file with windows line endings doesn't work 2013-09-20 1:52 ` re[6]: " Martin Gregory @ 2013-09-20 2:28 ` Duy Nguyen 2013-09-20 3:17 ` Jeff King 1 sibling, 0 replies; 10+ messages in thread From: Duy Nguyen @ 2013-09-20 2:28 UTC (permalink / raw) To: Martin Gregory; +Cc: Git Mailing List On Fri, Sep 20, 2013 at 8:52 AM, Martin Gregory <marting@adelaideinterim.com.au> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse checkout file with windows line endings doesn't work 2013-09-20 1:52 ` re[6]: " Martin Gregory 2013-09-20 2:28 ` Duy Nguyen @ 2013-09-20 3:17 ` Jeff King 2013-09-20 3:24 ` re[2]: " Martin Gregory 2013-09-20 18:06 ` Junio C Hamano 1 sibling, 2 replies; 10+ messages in thread From: Jeff King @ 2013-09-20 3:17 UTC (permalink / raw) To: Martin Gregory; +Cc: Duy Nguyen, Git Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* re[2]: sparse checkout file with windows line endings doesn't work 2013-09-20 3:17 ` Jeff King @ 2013-09-20 3:24 ` Martin Gregory 2013-09-20 3:38 ` Jeff King 2013-09-20 18:06 ` Junio C Hamano 1 sibling, 1 reply; 10+ messages in thread From: Martin Gregory @ 2013-09-20 3:24 UTC (permalink / raw) To: Jeff King, Martin Gregory; +Cc: Duy Nguyen, Git Mailing List >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse checkout file with windows line endings doesn't work 2013-09-20 3:24 ` re[2]: " Martin Gregory @ 2013-09-20 3:38 ` Jeff King 2013-09-20 3:52 ` re[2]: " Martin Gregory 0 siblings, 1 reply; 10+ messages in thread From: Jeff King @ 2013-09-20 3:38 UTC (permalink / raw) To: Martin Gregory; +Cc: Duy Nguyen, Git Mailing List 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* re[2]: sparse checkout file with windows line endings doesn't work 2013-09-20 3:38 ` Jeff King @ 2013-09-20 3:52 ` Martin Gregory 0 siblings, 0 replies; 10+ messages in thread From: Martin Gregory @ 2013-09-20 3:52 UTC (permalink / raw) To: Jeff King, Martin Gregory; +Cc: Duy Nguyen, Git Mailing List >> 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse checkout file with windows line endings doesn't work 2013-09-20 3:17 ` Jeff King 2013-09-20 3:24 ` re[2]: " Martin Gregory @ 2013-09-20 18:06 ` Junio C Hamano 1 sibling, 0 replies; 10+ messages in thread From: Junio C Hamano @ 2013-09-20 18:06 UTC (permalink / raw) To: Jeff King; +Cc: Martin Gregory, Duy Nguyen, Git Mailing List Jeff King <peff@peff.net> 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* sparse checkout file with windows line endings doesn't work @ 2013-09-16 13:20 Martin Gregory 2013-09-17 11:35 ` Duy Nguyen 0 siblings, 1 reply; 10+ messages in thread From: Martin Gregory @ 2013-09-16 13:20 UTC (permalink / raw) To: git Hi, Please see http://pastebin.com/zMXvvXuy It shows that if the .git/info/sparsecheckout file is in windows format (windows line ending) then it doesn't work. Thanks for any advice. This is git 1.8.3.msysgit.0 Martin ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: sparse checkout file with windows line endings doesn't work 2013-09-16 13:20 Martin Gregory @ 2013-09-17 11:35 ` Duy Nguyen 0 siblings, 0 replies; 10+ messages in thread From: Duy Nguyen @ 2013-09-17 11:35 UTC (permalink / raw) To: Martin Gregory; +Cc: Git Mailing List On Mon, Sep 16, 2013 at 8:20 PM, Martin Gregory <marting@adelaideinterim.com.au> wrote: > Hi, > > Please see http://pastebin.com/zMXvvXuy > > It shows that if the .git/info/sparsecheckout file is in windows format > (windows line ending) then it doesn't work. And it does work for me with CRLF endings (again tested on Linux). Can you send me your sparse-checkout file? Zip it if needed. I just wanted to make sure there's no weird visible characters there. If none is found, then I don't know what causes your problem. Perhaps msys guys can help. -- Duy ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-09-20 18:06 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CACsJy8BSqJjxNwz=p7sGO2jfByLfngvN0yq55URXkX=yV+OEfQ@mail.gmail.com>
[not found] ` <SDZYRFhOTCk2PDAuPVQvMjI4MjE1ODkw@IBMLT4>
2013-09-20 1:15 ` re[4]: sparse checkout file with windows line endings doesn't work Duy Nguyen
2013-09-20 1:52 ` re[6]: " Martin Gregory
2013-09-20 2:28 ` Duy Nguyen
2013-09-20 3:17 ` Jeff King
2013-09-20 3:24 ` re[2]: " Martin Gregory
2013-09-20 3:38 ` Jeff King
2013-09-20 3:52 ` re[2]: " Martin Gregory
2013-09-20 18:06 ` Junio C Hamano
2013-09-16 13:20 Martin Gregory
2013-09-17 11:35 ` Duy Nguyen
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 NNTP newsgroup(s).