On Wed, Feb 08, 2006 at 01:45:11PM -0800, Junio C Hamano wrote: > Ryan Anderson <ryan@michonline.com> writes: > > >> It's been a while since I looked at it the last time so it may > >> not even work with the current git, but here it is.. > > > > I'll take a look through this in greater detail later, hopefully your > > approach can be applied. Diff-analyzing is apparently tricky. > > Reading diff is tricky but I was lazy to match up the lines by > hand, which is also a real work ;-). Reading a diff is tricky, yes, but if you're willing to just throw RAM at the problem, it might not be quite as bad as I was trying at first. My current thought on how to get it more correct is this: foreach $rev (@revqueue) { foreach $parent (@{$revs{$rev}{parents}}) { my @templines = @{$revs{$rev}{lines}}; $revs{$parent}{lines} = apply_diff(\@templlines); } } The @lines arrays that get built will be entirely made up of hash or array references, so they just get reused for each successive file. When apply_diff() deletes a line from the new copy, it should mark that line as "claimed" by the current rev. I'm thinking that each element of @lines will look like this: { text => $text, in_original => [0 | 1], claimed_by => $rev, } at least to start. This method can sanity check itself by calling git cat-file and actually reading in each version of the file, and comparing it against the generated copy, aborting if we get the two out of sync. I'll see about implementing something along these lines this weekend, time permitting. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Feb 11 20:57:44 2006
This archive was generated by hypermail 2.1.8 : 2006-02-11 20:57:54 EST