Re: 'git status' is not read-only fs friendly

From: Junio C Hamano <junkio@cox.net>
Date: Feb 10, 2007, 16:46 UTC
Message-ID: <7vmz3mj6yo.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0702101131070.1757@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 10 quoted lines

> On Sat, 10 Feb 2007, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> 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.