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

> On Sat, 10 Feb 2007, Junio C Hamano wrote:
>
> >  (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 don't get me wrong.  I think that for 1.5.0 you should really do (0).
>

> So the fact is, "git status" _needs_ to refresh the index. Because if it
> doesn't, you'll see every file that doesn't match the index as "dirty",
> and that is not just a "technical issue".
>
> And yes, doing an "internal" refresh, like Junio's patch does, hides the
> issue, but it hides it BY MAKING THE OPTIMIZATION POINTLESS!
>
> I suspect Marco is testing some reasonably small git archive. With
> something like git itself, with less than a thousand files (and most of
> them fairly small, so rehashing them all is quick), the optimization may
> _feel_ like just a small technical detail.