Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Junio C Hamano wrote: > >> Makes me wonder >> >> - if we can/want to have a logic like this inside verify_filename(); > > Yes, I think so. I was worried that this would be confusing for some > command that looks to the worktree, like git grep without --cached, > but I suspect that worry was unfounded. > > The one case I am worried about is "git rev-parse". What is > "git rev-parse <path>" supposed to be used for? > >> - if we need a corresponding logic in either the previous else/if cascade >> that calls verify_non_filename(), or in verify_non_filename() itself. > > Yes. > > Is it safe to load the index so early? I can imagine a person trying > "git reset" to recover from a corrupted index; are we regressing in > that respect and how would one check for it? It is generally unsafe, I am afraid, and that is one of the reasons why verify_filename() does not look in the index (the other one was "it is merely a safety measure based on heuristics to help users, and no point spending extra code nor cycles", iow, deliberate laziness ;-)), making the proposal of this patch under discussion somewhat iffy. -- 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