Why is committing code so much faster than running diff?

Question

I like to check my commits before I push them upstream, so I always run a gitk (I like a little visual) before committing. I've noticed, though, that it's much quicker to commit the code first and then run gitk.

Slower:

1. [with uncommitted changes]
2. gitk
3. review uncommitted changes

Quite a bit faster: (haven't timed it, but it seems instant, as opposed to a few second lag)

1. git commit
2. gitk
3. review last commit
4. Revert or amend as necessary.

My understanding was the git basically runs a diff when it creates commits. So why does it take so much longer to diff the uncommitted code than to commit and review the last commit?

Answer 1

My understanding was the git basically runs a diff when it creates commits.

That, at least, is not true. When committing, Git simply archives the current index, precisely as it is. There are no diffs in a commit; rather, they are produced dynamically each time you actually view a commit.

Therefore, you also have the wrong idea, in a way. When you view your last commit with gitk, gitk actually runs git diff to produce what you see, so if you don't find that slow, then git diff simply isn't slow. :)

If producing a diff of the current working tree is slow, then I suspect that's more of a problem with your filesystem than anything else. I've never found it slow whatsoever, and I even use NFS. (So I must admit I don't quite understand how your filesystem could be much slower than that.)

Alternatively, it might just bit gitk that is slow. I've never used it much for reviewing the current state of the repository, usually preferring git status, git diff and/or git gui instead. (I do use gitk, but almost only to view the history and/or historical commits.)

A couple of tips:

• Leave gitk running in the background rather than restarting it every time.
• Check if running git diff itself is as slow as starting gitk.
• Just to be sure, run a git gc to optimize the repository.

EDIT: Now that you've mentioned that you run use Windows 7, it should be mentioned the Linus has quoted, when commenting on the design of Git, that he has made much use of his knowledge of the Linux kernel filesystem implementation for the speed of Git. The reason, then, for your slowness in comparing the working tree to the index may very well be that Windows 7 either has slower filesystem calls than Linux and/or simply doesn't like the way Git uses the filesystem.

This thread on the Git mailing list seems to be the same problem you're having, only worse. It has this quote, among others:

I think the simple reality is that Git was written with the assumption that stat is cheap and that isn't really the case on Windows, where the filesystem cache doesn't seem to do that well with this.

This answer on SO mentions a patch for msysgit which dramatically improves performance on Windows.