All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marco Costalba" <mcostalba@gmail.com>
To: "Nicolas Pitre" <nico@cam.org>
Cc: "Junio C Hamano" <junkio@cox.net>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"GIT list" <git@vger.kernel.org>,
	"Linus Torvalds" <torvalds@linux-foundation.org>
Subject: Re: 'git status' is not read-only fs friendly
Date: Sat, 10 Feb 2007 20:08:53 +0100	[thread overview]
Message-ID: <e5bfff550702101108k5dabd8d5o2487cc87bb1eafc7@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702101351430.1757@xanadu.home>

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.

  parent reply	other threads:[~2007-02-10 19:08 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-09 19:25 'git status' is not read-only fs friendly Marco Costalba
2007-02-09 19:56 ` Linus Torvalds
2007-02-09 20:19   ` Marco Costalba
2007-02-09 20:27     ` Junio C Hamano
2007-02-09 20:22   ` Junio C Hamano
2007-02-09 20:29     ` Morten Welinder
2007-02-09 23:27       ` Theodore Tso
2007-02-09 20:35     ` Marco Costalba
2007-02-09 20:59       ` Linus Torvalds
2007-02-10  0:12         ` Junio C Hamano
2007-02-10  0:16           ` Junio C Hamano
2007-02-10  2:51             ` [PATCH 1/2] run_diff_{files,index}(): update calling convention Junio C Hamano
2007-02-10  8:02               ` Marco Costalba
2007-02-10  8:20                 ` Junio C Hamano
2007-02-10  8:29                   ` Marco Costalba
2007-02-10  8:46                     ` Marco Costalba
2007-02-10 10:40                       ` Junio C Hamano
2007-02-10 11:25                         ` Marco Costalba
2007-02-10 15:13                           ` Junio C Hamano
2007-02-10 15:51                             ` Marco Costalba
2007-02-10  2:51             ` [PATCH 2/2] git-runstatus --refresh Junio C Hamano
2007-02-10 14:19 ` 'git status' is not read-only fs friendly Johannes Schindelin
2007-02-10 14:31   ` Marco Costalba
2007-02-10 14:41     ` Johannes Schindelin
2007-02-10 14:48       ` Marco Costalba
2007-02-10 14:51         ` Marco Costalba
2007-02-10 16:25           ` Junio C Hamano
2007-02-10 20:36             ` Johannes Schindelin
2007-02-11 21:57               ` Junio C Hamano
2007-02-11 22:09                 ` Johannes Schindelin
2007-02-11 22:28                   ` Johannes Schindelin
2007-02-11 22:30                   ` Junio C Hamano
2007-02-11 23:24                     ` Johannes Schindelin
2007-02-10 14:59         ` Johannes Schindelin
2007-02-10 15:45           ` Marco Costalba
2007-02-10 15:54           ` Nicolas Pitre
2007-02-10 16:27             ` Junio C Hamano
2007-02-10 16:40               ` Nicolas Pitre
2007-02-10 16:46                 ` Junio C Hamano
2007-02-10 17:03                   ` Nicolas Pitre
2007-02-10 18:00                     ` Junio C Hamano
2007-02-10 18:43                       ` Theodore Tso
2007-02-10 18:53                       ` Nicolas Pitre
2007-02-10 18:56                         ` Theodore Tso
2007-02-10 19:08                         ` Marco Costalba [this message]
2007-02-10 17:37                 ` Linus Torvalds
2007-02-10 18:51                   ` Nicolas Pitre
2007-02-11  6:33                   ` Junio C Hamano
2007-02-11  7:23                   ` Shawn O. Pearce
2007-02-10 20:40             ` Johannes Schindelin
2007-02-10 16:25           ` Junio C Hamano
2007-02-10 16:35             ` Marco Costalba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e5bfff550702101108k5dabd8d5o2487cc87bb1eafc7@mail.gmail.com \
    --to=mcostalba@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=nico@cam.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.