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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 9 Feb 2007, Marco Costalba wrote:
>
> In a repository under a mounted Windows directory (ntfs) I get this error:
> 
> $ git status
> fatal: unable to create '.git/index.lock': Read-only file system
> $
> 
> Is this correct? there exist a workaround? 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.

"git status" is kind of strange. It's really technically the engine behind 
the messages for "git commit": both in a very real technical sense (it's 
_literally_ the same script:"git-commit.sh" is not just "git-commit", but 
also "git-status"), but also in a very real historical "that is what the 
code was written for".

And you wouldn't think that it really needs write access, and you'd be 
largely correct, EXCEPT for the fact that git status actually does a 
refresh of the index, to make sure that we don't claim that something is 
dirty just because somebody has touched the file.

IOW, there's an implicit "git update-index --refresh" as part of 
calculating the status, and that's the thing that wants to lock the index 
file (and thus write to the filesystem).

> All other commands commonly used to browse a repository seems to work
> well, without pretending to write stuff.

"git status" doesn't "pretend" to write stuff. It really does. 

You *can* just use "git-runstatus" instead. That's the command that 
actually does all the heavy lifting. But you can see the difference by 
doing this:

	touch Makefile
	git runstatus

vs

	touch Makefile
	git status

Notice how the "runstatus" one claims that Makefile is "modified:". That's 
exactly because it doesn't do the index refresh.

			Linus