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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html