From: Chris Mason Date: Wed, 27 Apr 2005 18:23:37 GMT Subject: Re: Finding file revisions Message-ID: <200504271423.37433.mason@suse.com> In-Reply-To: On Wednesday 27 April 2005 13:34, Linus Torvalds wrote: > On Wed, 27 Apr 2005, Chris Mason wrote: > > Is there a faster way? > > Yes. Tell "diff-tree" what your desired files are, and it will cut down > the amount of work by a _lot_ (because then diff-tree doesn't need to > recurse into subdirectories that don't matter). Thanks. I originally called diff-tree without the file list so that I could do the regexp matching, but this is probably one of those features that will never get used. My test case here is a tree with 400 commits, giving diff-tree the file list brings us down from 16s to 9s on a cold cache. Hot cache is about 1.5 seconds on both. > > > This will scale pretty badly as the tree grows, but > > I usually only want to search back a few months in the history. So, it > > might make sense to limit the results by date or commit/tag. > > With more history, "rev-list" should do basically the right thing: it will > be constant-time for _recent_ commits, and it is linear time in how far > back you want to go. Which seems quite reasonable. > > And diff-tree is obviously constant-time (and very fast at that, > especially if you limit it to just a few files, since then it won't even > bother with any other subdirectories). Usually the question I will want to ask is "how did foo.c change since tag X", which usually won't go back more then a few months. This should be reasonable, and I'd rather not slow down common operations adding extra indexing for the uncommon file-changes run. So, new prog attached. New usage: file-changes [-c commit_id] [-s commit_id] file ... -c is the commit where you want to start searching -s is the commit where you want to stop searching -chris