On Tue, Jul 07, 2009 at 01:30:47PM -0700, Eric Raible wrote: > > I personally do not think it is worth it. If you change the crlf, > > clean/smudge, or anything of that sort, just doing a "rm .git/index" > > followed by "git reset --hard" would restore sanity to your work tree, no? > > Is there any technical reason why "git reset --hard" shouldn't repopulate > the index by doing a "git read-tree" or equivalent [1]? After all the > docs claim it > "Matches the working tree and index to that of the tree being switched to". Yes; relying on the stat cache is what makes "git reset --hard" really fast, instead of having to re-hash each file. The real problem is that we are invalidating the contents of that cache, but not marking the entry as dirty. Right now we don't mark the entries, and you get stale data until you manually mark them as dirty. But marking them dirty on every reset will mean that reset can't make use of the cache, which is slow. So ideally we would have a way of marking them dirty only when necessary. One way would be a "git reset --hard --reset-me-harder", but that obviously still involves manual work; you're just making the command a little easier to find and use. As I suggested before, you could include the changed bits (i.e., the attributes and config) as part of the cache validity information. But I suspect it would be hard to implement, as it involves new fields in the index. It also involves arbitrary user commands, so getting it 100% right would be impossible (e.g., we can record the string "my-clean-filter" as the filter name, but we can't know when that filter's behavior has changed); however, in practice, I think we can assume that a string containing a text command will have stable output. -Peff -- 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