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(-)
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