Re: git commit results in many lstat()s

On Thu, Feb 02, 2017 at 12:14:30AM +, Gumbel, Matthew K wrote: > I'm testing such a change locally. Git test suite seems to be running for > quite > a while. Do you know any way to run it in parallel or otherwise speed it > up? I usually do something like the following: make -j3 all &&

RE: git commit results in many lstat()s

"Junio C Hamano writes: "Gumbel, Matthew K" writes: >> Yes, I think that when the user passes --only flag to git-commit, then git >> does not >> need to call refresh_cache() in prepare_index() in builtin/commit.c. >> >> I may experiment

Re: git commit results in many lstat()s

"Gumbel, Matthew K" writes: > "Junio C Hamano" writes: >> There probably are other things that can be optimized. > > Yes, I think that when the user passes --only flag to git-commit, then git > does not > need to call refresh_cache() in

RE: git commit results in many lstat()s

"Junio C Hamano" writes: > There probably are other things that can be optimized. Yes, I think that when the user passes --only flag to git-commit, then git does not need to call refresh_cache() in prepare_index() in builtin/commit.c. I may experiment with that. Do you see

Re: git commit results in many lstat()s

"Gumbel, Matthew K" writes: > I do not understand why git commit must call lstat() on every file > in the repository, even when I specify the name of the file I want > to commit on the command line. Assuming the "COPYING" and "README.md" files are already tracked:

git commit results in many lstat()s

Hello, My high level problem is to speed up git commit on a large repository stored on NFS filesystem. I see via strace that it is slow because it makes a large number (~50,000) of lstat() calls in serial. Every call is a round-trip to the NFS server. I do not understand why git commit must