Jeff King <p...@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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to