threads / discuss / 34970

Re: re[4]: sparse checkout file with windows line endings doesn't work

Subject: Re: re[4]: sparse checkout file with windows line endings doesn't work

## tl;dr

8 messages between Sep 20, 2013 and Sep 20, 2013.

replies: 7people: 4as markdown or json

Duy Nguyen· Sep 20, 2013, 01:15 UTC · lore

On Fri, Sep 20, 2013 at 7:01 AM, Martin Gregory <marting@adelaideinterim.com.au> wrote:

Show 10 quoted lines
> 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· Sep 20, 2013, 01:52 UTC · re: Duy Nguyen · lore

re[6]: sparse checkout file with windows line endings doesn't work

Thanks Duy for the fast response.
Show 9 quoted lines
> 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· Sep 20, 2013, 02:28 UTC · re: Martin Gregory · lore

Re: re[6]: sparse checkout file with windows line endings doesn't work

On Fri, Sep 20, 2013 at 8:52 AM, Martin Gregory <marting@adelaideinterim.com.au> wrote:

Show 20 quoted lines
> 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· Sep 20, 2013, 03:17 UTC · re: Martin Gregory · lore

Re: sparse checkout file with windows line endings doesn't work

On Fri, Sep 20, 2013 at 11:22:01AM +0930, Martin Gregory wrote:
Show 10 quoted lines
> 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· Sep 20, 2013, 03:24 UTC · re: Jeff King · lore

re[2]: sparse checkout file with windows line endings doesn't work

Show 20 quoted lines
>>  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· Sep 20, 2013, 03:38 UTC · re: Martin Gregory · lore

Re: sparse checkout file with windows line endings doesn't work

On Fri, Sep 20, 2013 at 12:54:45PM +0930, Martin Gregory wrote:
Show 11 quoted lines
> >>  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· Sep 20, 2013, 03:52 UTC · re: Jeff King · lore

re[2]: sparse checkout file with windows line endings doesn't work

Show 5 quoted lines
>>  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· Sep 20, 2013, 18:06 UTC · re: Jeff King · lore

Re: sparse checkout file with windows line endings doesn't work

Jeff King <peff@peff.net> writes:
Show 19 quoted lines
> 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.

← back to recent threads