Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Tue, 12 Feb 2008, Junio C Hamano wrote: >> >> You can drop the "line count" idea and instead count the "amount >> of damage" done to the preimage, just like we do in the rename >> similarity computation. >> >> The attached patch is just an outline. There may need special >> cases for unmerged paths. > > Ouch. I like the concept and the result, but an not a huge fan of the the > implementation. The problem with this is that it makes the whole damage > computation something separate from the earlier phases. > > So it actually seems to add a lot of cost. Right now there is basically > zero added cost to just adding a "--dirstat" to one of my common > operations, which is > > git diff -M --stat --summary > > (that's what I do on merges). > > Wouldn't it be nicer to merge it with one of the stages we did earlier by > simply saving the data. If not the --stat phase, then the -M phase? We could add one ulong to diff_filepair struct to record "damage", and populate it inside diffcore_rename(). Obviously: - You would need to diffcore_count_changes() in separate phase if you do not use -M; - Even if you use -M, we do not run diffcore_count_changes() for unrenamed paths during diffcore_rename(), so you would need to do that separately. By the way, if you run "git diff --summary --dirstat -M" (that is, without --stat), we will not have to run diffstat at all. Instead, we only run diffcore_count_changes(), which can be reused for renamed paths if we keep it in diff_filepair struct. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
