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



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

Reply via email to