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

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

Nicolas Pitre <nico@cam.org> writes:

> You're making assumption about work flows and using that to justify 
> command implementation flaws.  This is not exactly "user friendly".

I do not necessarily agree that making the command to follow a BCP workflow is "user unfriendly", but that does not pertain what I will end up saying in this message, which is to agree with you.

> But a command that is called "status" should provide a "status" even if 
> the file system is read-only nevertheless.  The index updating business 
> that is done behind the scene is and should be an opportunistic 
> optimization, but it should not prevent status reporting.

Fair enough.  That leaves us two options.

 (0) Do nothing.

 (1) We keep the current "git-status [-v] [-a] [[-i|-o] <paths...>]"
     command line and do the necessary index manipulation
     in-core without writing it out (see git-commit.sh for
     details of what it involves).

 (2) We drop the support for any command line parameter from
     "git-status", apply my two patches for Marco to
     "git-runstatus", and rename "git-runstatus" to
     "git-status".

If I have to pick between the two, I would probably pick (2). While (1) would essentially mean doing "git-commit" entirely in-core without writing the index out until we really make the commit, which is a good thing in itself in the longer term, it is out of the question this late in the game for 1.5.0.

And now I think what Linus suggests also make sense -- we could tweak (2) so that git-runstatus actually writes the refreshed index out when it finds that it _can_ write it (and drop subsequent internal refresh).

Now, I am heading out.