Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > This is on purpose. Commit f8a9d42 (read-tree: further loosen "working > file will be lost" check. - 2006-12-04) allowed ignored files to be > overwritten. Perhaps we can have a config to tighten the check again? No. The real issue is that we have only two classes of paths. Either ignored or unignored. If we see an unignored path not yet tracked, we notice and suggest "that file might be something valuable and you may forgot to add" in "status" output. In that sense, "unignored" is a synonym of "worth keeping". Most of the time, "ignored" is also the same as "can be safely discarded" (think: *.o files that can be recreated). If you do not allow them to be discarded, switching from a branch that has "builtin/hello.c" and leaves an ignored compilation artifact "builtin/hello.o" to another branch that did not have "builtin/" directory (probably it is "builtin-hello.c" on that branch), or even worse, a plain text file "builtin", would stop and get you into a horrible habit of constantly saying "checkout -f". Even though there may be cases where there are some files that are not tracked, that you may not want to add, but you may still want to keep, because we have only two ignored/unignored classes, that is how we have done things. If you really want to fix this to everybody's satisfaction, you need to introduce the third class, ignored-but-precious (IIRC, tla had such a concept), and treat them as "not worth nagging about potentially forgotten as an add target" but still "not automatically nukeable". -- 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