Re: [gentoo-scm] Re: Git Validation - Update

[Rich Freeman]

On Wed, Oct 17, 2012 at 8:49 AM, Peter Stuge <peter@×××××.se> wrote:
> Rich Freeman wrote:
>> I'm storing a history of when files change, starting by looking at
>> commits in complete isolation.
>
> The more gitty way would be to use the trees.

I was being a bit informal in my description.  The actual map/reduce
steps don't look at commits at all - only trees/blobs.  The initial
parse of the commits extracts all the trees and the commit info we
care about.  There is no way to get to blobs from commits except
through trees.

>
> It would be two passes. First pass tree[n%2=0] with tree[n+1] and on
> second pass tree[n%2=1] with tree[n+1].

Sure, and you can break that down much further.  If you write each
commit with the one preceeding it on the same line you can even do it
with map.  It is a big change in the algorithm.  Actually, by doing it
that way you could just do a complete pairwise compare of the whole
tree and glean everything on a single iteration. I think.  To do it
I'd just write each line of my csv with twice as many fields - the
second half of each line being the first half of the next, or the one
before, or however it works.  First or last would be a special case.

>> One way that comes to mind is to do a second pass that just looks
>> for deletions, using the cvs data to cheat - each deletion could be
>> checked in parallel doing a pairwise compare on a single file.
>
> It would compare trees, not files, but sure, that works too. It will
> not notice if something extra has been deleted in git however, if the
> same file does not have any further changes in CVS.

Sort-of.  If a file is deleted early then it will show up as being
missed when the file should have been deleted.  Files that never were
deleted but which were deleted in git are very easy to detect - a
simple file compare of a checkout of each would spot that.

Rich