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

On 2/10/07, Nicolas Pitre <nico@cam.org> wrote:
> 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).
>

I agree on doing (0) for 1.5.0 and the following Linus lines make me
wonder if is better doing (0) also after 1.5.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.

If current 'git runstatus' on a NTFS directory, Linux side, show as
dirty _all_ the repo files, then in case of big repos, as Linus
pointed out, a possible future 'git runstatus --refresh' will be
terribly slow because must filter out as false positives _all_ the
repo files. And worst, have to do it *any time* it is run.

So perhaps the two patches of Junio _seems_ to work to me just because
repo is small, is qgit4 indeed, but on a Linux tree would be veeery
slow, so slow that probably is better to avoid completely and report
quickly to user an empty set, being a corner case user will understand
;-)

Marco

P.S: I know I'm looking for flames but, if git-status HAVE to write
the index and if 'status', as Nicolas points out, is a word that
suggest a read only function, why don't change the name of the
command.....'git sync-index' as example.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html