Hi, On Mon, 12 Feb 2007, Bruno Haible wrote: > > Yes, because there were only 147 commits which changed the file. But git > > looked at all commits to find that. > > Ouch. Not so ouch: > > Basically, we don't do file versions. File versions do not make sense, > > since they strip away the context. You could have it faster, but you'd break a very useful concept by doing so. > Is there some other concept or command that git offers? I'm in the > situation where I know that 'tr' in coreutils version 5.2.1 had a > certain bug and version 6.4 does not have the bug, and I want to review > all commits that are relevant to this. So, only look at those: git log v5.2.1..v6.4 tr.c (provided you have the tags for the releases). You can start reviewing right away, since the output will start very fast (much faster than it takes to complete the log!). If you want to get the patches to tr.c with the logs, just add "-p": git log -p v5.2.1..v6.4 tr.c > > > 2) Why so much system CPU time, but only on MacOS X? > > > > Probably the mmap() problem. Does it go away when you use git > > 1.5.0-rc4? > > No, it became even worse: git-1.5.0-rc4 is twice as slow as git-1.4.4 for > this command: > git-1.4.4: 25 seconds real time, 24 seconds of CPU time (12 user, 12 system) > git-1.5.0: 50 seconds real time, 39 seconds of CPU time (20 user, 19 system) Hmmm. I don't have MacOSX any more, so I cannot investigate. You might find this the perfect opening into working on git ;-) Hth, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html