Re: speed of git reset -- file

[Joey Hess <joey@kitenet.net>]

[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]

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?

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

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

-- 
see shy jo

[1] Two or three times the number of files as linux-2.6.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]