Jeff King <peff@xxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html