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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 20, 2013, 18:06 UTC
Message-ID: <xmqqa9j7qsf3.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20130920031705.GA15101@sigill.intra.peff.net>

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.