git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 0/2] Two mostly janitorial patches for builtin/blame.c
@ 2014-01-22  0:20 David Kastrup
  2014-01-22  0:20 ` [PATCH 1/2] builtin/blame.c: struct blame_entry does not need a prev link David Kastrup
  2014-01-22  0:20 ` [PATCH 2/2] Eliminate same_suspect function in builtin/blame.c David Kastrup
  0 siblings, 2 replies; 4+ messages in thread
From: David Kastrup @ 2014-01-22  0:20 UTC (permalink / raw)
  To: git; +Cc: David Kastrup

Same series as sent previously, just signed off this time.

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

^ permalink raw reply	[flat|nested] 4+ messages in thread
* [PATCH 0/2] Two janitorial patches for builtin/blame.c
@ 2014-01-19 18:57 David Kastrup
  2014-01-19 18:57 ` [PATCH 2/2] Eliminate same_suspect function in builtin/blame.c David Kastrup
  0 siblings, 1 reply; 4+ messages in thread
From: David Kastrup @ 2014-01-19 18:57 UTC (permalink / raw)
  To: git; +Cc: David Kastrup

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-01-22  0:20 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-22  0:20 [PATCH 0/2] Two mostly janitorial patches for builtin/blame.c David Kastrup
2014-01-22  0:20 ` [PATCH 1/2] builtin/blame.c: struct blame_entry does not need a prev link David Kastrup
2014-01-22  0:20 ` [PATCH 2/2] Eliminate same_suspect function in builtin/blame.c David Kastrup
  -- strict thread matches above, loose matches on Subject: below --
2014-01-19 18:57 [PATCH 0/2] Two janitorial patches for builtin/blame.c David Kastrup
2014-01-19 18:57 ` [PATCH 2/2] Eliminate same_suspect function in builtin/blame.c David Kastrup

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).