On Thu, Jul 14, 2005 at 10:08:31AM +0100, Catalin Marinas wrote:
> Russell King <[EMAIL PROTECTED]> wrote:
> > 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.
> Does git-ls-files --unmerged show any files?
No, and it returns fairly quickly:
$ /usr/bin/time git-ls-files --unmerged
0.29user 0.03system 0:00.43elapsed 73%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+655minor)pagefaults 0swaps
Actually, I should've left the sh -x /usr/bin/cg-diff drivers/serial/8250.c
running a little longer. It's not the git-update-cache command which
is taking the time, it's git-diff-cache.
Running the diff several times, both with and without changes to
drivers/serial/8250.c, it seems that sometimes it's faster. I guess
it has to do with dentry invalidation...
However, the point is - I've only asked for _one_ file. Why do we need
to look at _every_ file in the tree?
I could understand this behaviour if I'd asked for a diff across the
whole tree, but I didn't.
Internally, the sha1 of the unmodified drivers/serial/8250.c should be
known, so should be trivial to unpack that and generate a diff. Given
the cache, this should be something which should be lightning fast
when the requested fileset to diff is already known.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html