sparse checkout file with windows line endings doesn't work

sparse checkout file with windows line endings doesn't work

[Martin Gregory]

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

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

[Duy Nguyen]

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

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

[Duy Nguyen]

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

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

[Martin Gregory]

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

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

[Duy Nguyen]

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

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

[Jeff King]

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

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

[Martin Gregory]

>>  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

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

[Jeff King]

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

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

[Martin Gregory]

>>  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

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

[Junio C Hamano]

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.