re[2]: sparse checkout file with windows line endings doesn't work

From: Martin Gregory <marting@adelaideinterim.com.au>
Date: Sep 20, 2013, 03:24 UTC
Message-ID: <SDZYUVdaTCUzXD8wPVQvMjQwMzM4MTcx@IBMLT4>
In-Reply-To: <20130920031705.GA15101@sigill.intra.peff.net>

Show 20 quoted lines

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