>> 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...
Senior Consultant, Adelaide Interim
P: +61 8 7200 5350
M: +61 402 410 971
F: +61 8 7200 3725
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