Thread (5 messages) flat view 5 messages, 4 authors, 2018-12-13

Re: [PATCH on master v2] revision: use commit graph in get_reference()

From: Derrick Stolee <hidden>
Date: 2018-12-13 16:20:22

On 12/12/2018 8:27 PM, Jeff King wrote:
On Wed, Dec 12, 2018 at 11:58:12AM -0800, Jonathan Tan wrote:
quoted
quoted
Yeah, this was the part that took me a bit to figure out, as well. The
optimization here is really just avoiding a call to lookup_commit(),
which will do a single hash-table lookup. I wonder if that's actually
worth this more complex interface (as opposed to just always taking an
oid and then always returning a "struct commit", which could be old or
new).
Avoidance of lookup_commit() is more important than an optimization, I
think. Here, we call lookup_commit() only when we know that that object
is a commit (by its presence in a commit graph). If we just called it
blindly, we might mistakenly create a commit for that hash when it is
actually an object of another type. (We could inline lookup_commit() in
parse_commit_in_graph_one(), removing the object creation part, but that
adds complexity as well.)
I was thinking we would only do so in the happy path when we find a
commit. I.e., something like:

   obj = lookup_object(oid); /* does not auto-vivify */
   if (obj && obj->parsed)
	return obj;

   if (we_have_it_in_commit_graph) {
	commit = obj || lookup_commit(oid);
	fill_in_details_from_commit_graph(commit);
	return &commit->obj;
   } else {
	return parse_object(oid);
   }

which is more along the lines of that parse_probably_commit() that
Stolee mentioned.
This approach is what I had in mind. Thanks for making it more concrete!

-Stolee
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help