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. -- Russell King - 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
