This is more a warmup than anything else: I'm actually doing a quite more involved rewrite of git-blame right now. But it's been a long time since I sent patches for Git, so I'm starting out with something reasonably uncontroversial. Patch 1 is a no-brainer: maintaining reverse links is not worth the trouble if you are not going to use them. Now one can be "conservative" and say "but git-blame is awfully inefficient and maybe we'll need them in a more efficient version". I can answer this with "no": the kind of stuff that would make things more efficient does not require backlinks.
Patch 2 is a bit more tricky: basically its contention is that I understand some implications of the code better than its author appeared to do. Which is somewhat optimistic. Since my followup work depends on my understanding this correctly, it's better to make sure of that by handing in a nicely isolated patch for review. It's conceivable that my understanding of the commit->util cache is not fully satisfactory. I don't use it in my followup work anyway, but it still would be nice to get this code path cleaned out in advance. I don't expect measurable performance improvements from these two patches: their main purpose is to get some cruft out of the way so that the heavy-duty patches actually dealing with the performance sinks will be a bit more focused. And of course, getting the ball rolling again. David Kastrup (2): builtin/blame.c: struct blame_entry does not need a prev link Eliminate same_suspect function in builtin/blame.c builtin/blame.c | 38 ++++++++++---------------------------- 1 file changed, 10 insertions(+), 28 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
