Re: Finding file revisions

From: Chris Mason <mason@suse.com>
Date: Apr 27, 2005, 18:23 UTC
Message-ID: <200504271423.37433.mason@suse.com>
In-Reply-To: <Pine.LNX.4.58.0504271027460.18901@ppc970.osdl.org>

On Wednesday 27 April 2005 13:34, Linus Torvalds wrote:

Show 6 quoted lines

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

Show 12 quoted lines

>
> > 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