>> 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... Regards, Martin -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html