Re: speed of git reset -- file

[Jeff King <peff@peff.net>]

On Wed, Jun 01, 2011 at 04:16:29PM -0400, Joey Hess wrote:

> Jeff King wrote:
> > So implementing the "optimization" to drop the refresh here doesn't seem
> > worth it. It inroduces an awful inconsistency, and it probably isn't
> > saving much in practice. Lots of other commands will end up stat'ing
> > everything, anyway. Users with giant repos or slow stat calls are
> > probably better off using assume-unchanged, which would help this and
> > many other situations.
> 
> Sounded like git-reset -q file could be optimised to not reread the
> index without any visible inconsistency?

No, there would still be a visible inconsistency. For example:

  $ git reset -q -- file
  $ git diff-files

might leave stat-dirty entries in the index, but:

  $ git reset -- file
  $ git diff-files

would not.

In practice, it doesn't matter that much, because you would probably run
the porcelain "git diff" instead of the plumbing "git diff-files"
anyway. And "git diff" refreshes the index itself, so the behavior
change is not that important. But then, as you see, we end up refreshing
the index defensively a lot, anyway, so saving the one refresh from
reset may be lost in the noise (unless you are doing some tight loop of
resets).

So what you could do with assume-unchanged (or much better, the
autorefreshindex variable that Junio recommends), would be to shut off
_all_ of the unnecessary refreshes, not just this one.

> My experience with semi-large trees[1] is that I have to remember to use
> "git status ." in a subdir; that "git commit -a" is of course slow when
> I need to use it; and that the index gets big and things that need to
> update it can become somewhat slow especially on slow disks, but that

Generally I find that the stats are very fast because everything is in
cache, and the disk doesn't come into it at all. Are you on an OS
besides Linux, or on a machine with low memory?

> otherwise git scales fairly well and has good locality, and that it's
> easy to reason about what operations are global and avoid them.
> So this git-reset behavior was surprising.

Yeah, git is generally very good about touching only the pieces of data
you need to complete the current operation. But I think the decision was
made long ago that "update-index --refresh" was not too expensive to do
it in most porcelain-ish commands, especially since the results are much
better (e.g., more accurately indicating modified files after a reset).

> assume-unchanged seems like it would add a lot of work when merging.

Yeah, Junio's autorefresh suggestion is much better.

-Peff