Re: Finding file revisions

From: Chris Mason <mason@suse.com>
Date: Apr 28, 2005, 11:56 UTC
Message-ID: <200504280756.58293.mason@suse.com>
In-Reply-To: <20050428084156.GK17682@himi.org>

On Thursday 28 April 2005 04:41, Simon Fowler wrote:

Show 16 quoted lines

> I've got a version of this written in C that I've been working on
> for a bit - some example output:
>
> +040000 tree    bfb75011c32589b282dd9c86621dadb0f0bb3866        ppc
> +100644 blob    5ba4fc5259b063dab6417c142938d987ee894fc0        ppc/sha1.c
> +100644 blob    c3c51aa4d487f2e85c02b0257c1f0b57d6158d76        ppc/sha1.h
> +100644 blob    e85611a4ef0598f45911357d0d2f1fc354039de4       
> ppc/sha1ppc.S commit
> b5af9107270171b79d46b099ee0b198e653f3a24->a6ef3518f9ac8a1c46a36c8d27173b1f7
>3d839c4
>
> You run it as:
> find-changes commit_id file_prefix ...
>
> The file_prefix is a path prefix to match - it's not as flexible as
> regexes, but it shouldn't be too much less useful.

I dropped the regexes for speed with diff-tree, they weren't that important to me...The features I was going for are:

1) ability to see the changeset comments in the output.
2) ability to look for revs on more than one file at a time.  The single file 
limit in bk revtool always bugged me.
3) Some quick cut n' paste method to generate the changeset diff.  This is why 
I do diff-tree -r in the output, so I can just copy into a different window 
and go.

Your c version would hopefully end up faster on cpu time by limiting the number of times we read/decompress the commit files.

-chris