Re: git commit results in many lstat()s

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 1, 2017, 22:11 UTC
Message-ID: <xmqq8tppo92x.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <DA0A42D68346B1469147552440A645039A9C56D4@ORSMSX115.amr.corp.intel.com>

"Gumbel, Matthew K" <matthew.k.gumbel@intel.com> 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:

    $ >COPYING
    $ >README.md
    $ git commit COPYING

would open an editor, in which you would see list of files under "Changes to be committed", "Changes not staged for commit", etc. Among the second class you would see README.md listed.

To figure out what paths are "changed", without having to open all files and compare their contents with what is recorded in the commit you are building on top of, we do lstat(2) to see if the timestamp (and other information in the inode) of the files are the same since you checked them out of HEAD.

    $ git commit --no-status COPYING

would reduce the number of lstat(2) somewhat, because the codepath is told that it does not have to make the list to be shown in the editor. So would

    $ git commit -m "empty COPYING" COPYING

These two only halve the number of lstat(2), by taking advantage of the fact that the list of "modified files" does not have to be built. There probably are other things that can be optimized.