Nicolas Pitre <nico@xxxxxxx> writes: > On Sat, 10 Feb 2007, Junio C Hamano wrote: > >> Nicolas Pitre <nico@xxxxxxx> writes: >> ... >> > Because git-status itself is conceptually a read-only operation, and >> > having it barf on a read-only file system is justifiably a bug. >> >> I do not 100% agree that it is conceptually a read-only operation. > > It is. It's the technical issue that makes it not so. I do not think so. It is a workflow issue that user indicates the cache cleanliness information does not matter anymore. Is it wrong for "git-status" to be losing the cache cleanliness information? The intended audience of that program is those who are about to make a commit in the repository, as they are asking "what would I be committing?" Up to that point, they may have cared about the reminder they get from "git diff" that they edited a file and then ended up reverting the whole edit they did to that file (I find that empty diff from "git diff" often very useful, although I felt "Huh?" when I was new to git). But when they ask "git status", they care more about the real change, and at that point (since they feel they may be ready to make a commit -- and that is the whole point of running "git-status") they do want to lose the cache cleanliness information. So "git-status" to be read-write application to discard the cache-cleanliness information is probably a good thing. - 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