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

From: Marco Costalba <mcostalba@gmail.com>
Date: Feb 9, 2007, 20:19 UTC
Message-ID: <e5bfff550702091219n4df5531ek6be2cd04f00be650@mail.gmail.com>
In-Reply-To: <Pine.LNX.4.64.0702091148060.8424@woody.linux-foundation.org>

On 2/9/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:

>
>

Show 9 quoted lines

> 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).
>

------ cut ------

Show 16 quoted lines

>
> 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.
>

Sorry, perhaps it is a silly question, but why git index should be different after just touching a file?

IOW is it not possible that "git update-index --refresh" exists without modifing the index, just because ther's nothing to modify?

So, finally, could be possible making "git status" taking the lock only _after_ has checked there's something new to write to the index? So to avoid write access in most cases ? (expecially with repo mounted on a read-only fs)

Thanks Marco