Re: Commit performance, or lack thereof

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 23, 2009, 02:20 UTC
Message-ID: <7vvdkf1dax.fsf@alter.siamese.dyndns.org>
In-Reply-To: <m3r5v39zzz.fsf@lugabout.jhcloos.org>

James Cloos <cloos@jhcloos.com> writes:

> Starting in the kernel tree, if one edits and adds a single file and
> then commits it w/o specifying the file name as an argument to commit,
> ...
> OTOH, if one does specify the filename as an argument to commit,...

When you do:

    git add something && git commit

the commit step is just "write the index out as a tree, create a commit object to wrap that tree object". It never has to look at your work tree and is a very cheap operation.

On the other hand, if you do:

    some other random things && git commit pathspec

the commit step involves a lot more operations.  It has to do:

    - create a temporary index from HEAD (i.e. ignore the modification to
      the real index you did so far with your earlier "git add");

    - rehash all the paths in the work tree that matches the pathspec and
      add them to that temporary index; and finally

    - write the temporary index out as a tree, create a commit object to
      wrap that tree object.

The second step has to go to your work tree, and if you have a slow disk, or your buffer cache is cold, you naturally have to pay.

So it is not surprising at all if you observe that the latter takes more time and resource than the former, although there could be something wrong in your set-up that you need to spend 300M for it. It is fundamentally a more expensive operation.