Re: Is cogito really this inefficient

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 14, 2005, 15:26 UTC
Message-ID: <Pine.LNX.4.58.0507140813150.19183@g5.osdl.org>
In-Reply-To: <20050714083700.A26322@flint.arm.linux.org.uk>

On Thu, 14 Jul 2005, Russell King wrote:

> 
> cg-update origin
> and then I edited drivers/serial/8250.c

Hmm..

Show 6 quoted lines

> it appears that cg-diff does a
> 
> 	git-update-cache --refresh >/dev/null
> 
> each time it's run, which is taking the bulk of the time.  Also note
> that curiously, it exits with status 1.

That part is normal - a update-cache is fast (it takes me 0.08 sec for the kernel) if the cache is already mostly up-to-date, and the non-zero exit status just means that some file was different (ie it's telling the caller that there are edits in your tree - drivers/serial/8250.c).

The update-cache is slow only if the index isn't up-to-date, which can happen either if somebody plays games with the index, or if somebody touches all the files in the tree.

It's quite possible that some path in cg-update ends up not updating the index properly. For example, I notice that the "fast-forward" uses "git-checkout-cache -f -a", which can do so (lack of "-u" fila), but then it does do a "git-update-cache --refresh" later, so that doesn't seem to be it either.

If you do a "git-diff-files" every once in a while, it will _scream_ at you whenever you have files that aren't up-to-date in the cache. That's normal in small doses, of course (eg your edit of drivers/serial/8250.c would make that one not up-to-date), but if you get a _lot_ of files listed, that's usually a sign that something screwed up your index.

		Linus