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

From: Junio C Hamano <junkio@cox.net>
Date: Feb 10, 2007, 16:25 UTC
Message-ID: <7vveiaj7y5.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0702101554170.22628@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 17 quoted lines

>> > > > > I just need to know if current working directory is clean and report
>> > > > > back to qgit user, so read-only access would be ok for me.
>>
>> [... talking about a patch to introduce --refresh to git-status ...]
>>
>> Well, I tested the patch and indeed it helps a lot ;-)
>
> Not really. The thing is, git-status does a lot more than what you need. 
> And what you need is _only_ what "git diff --name-only HEAD" does already!
>
> It _also_ checks the index, it _also_ only checks the files with different 
> stat information, but it does _not_ try to update the index and prepare a 
> message to be displayed when committing.
>
> So, what is the big problem about accepting that patching git-status for 
> one obscure use is wrong, wrong, wrong, when git-diff already does what is 
> needed???

It really depends on what Marco means by "if cwd is clean".

If by "clean" Marco means "no differences after discarding cache cleanliness information", "git-diff" is not quite it, as it shows the differences including the cleanliness of the cache entry.

"git-status", as Marco found out in the message that started this thread, loses the cache cleanliness information when it runs [*1*].

If he cares about cache cleanliness information, "git-diff" is the right thing to use, and using "git status" is wrong -- it not only does more than he needs (as you pointed out), it loses information, which may be worse, depending on why he wants to know.

[Footnote]

*1* To achieve that, it has to write into the repository.

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.