Jakub Narebski <jnareb@xxxxxxxxx> writes: >> The intention was that it shouldn't necessarily be the (strict) parent >> of the change (changed segment), since it may or may not have changed >> in the strict parent commit. The intention was that it >> "starts"/"opens" the parent commit so that "git" would start from >> there and find the actual change/commit where that line/segment has >> changed. And it has worked pretty fine for me when data-mining >> (something I do quite often) code evolution. Yes, but the current scheme breaks down in another way. When $full_rev added many lines to the file, and you are adding the link to for a line near the end of the file and such a line may not exist. This cannot be cheaply done even inside blame itself. Another breakage is even though $full_rev^ _may_ exist (iow, $full_rev might not be the root commit), the file being blamed may not exist there (iow $full_rev might have introduced the file). Instead of running "rev-parse $full_rev^", you would at least need to ask "rev-list -1 $full_rev^ -- $path" or something from the Porcelain layer, but unfortunately this is rather expensive. Because blame already almost knows if the commit the final blame lies on has a parent, it would be reasonably cheap to add that "parent or nothing" information to its --porcelain (and its --incremental) format if we wanted to. -- 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
