Thread (5 messages) flat view 5 messages, 3 authors, 2021-07-14

Re: [PATCH v2] load_ref_decorations(): fix decoration with tags

From: Martin Ågren <hidden>
Date: 2021-07-13 21:53:06

Possibly related (same subject, not in this thread)

Earlier, Junio C Hamano [off-list ref] wrote:
quoted
quoted
Note how this commit could have been done as an optimization before
88473c8bae: When our peeling hits a non-tag, we won't parse that tagged
object only to immediately end the loop.
Yep, thanks for mentioning this, as it's somewhat subtle.
It is too subtle that I am not sure what the paragraph wants to say.
Then:
Jeff King [off-list ref] writes:
quoted
quoted
Puzzled.
...and the answer is that we don't need to parse it. The tag object
mentions the type of what it points to, and we use lookup_commit(), etc,
to create the object pointed to by its "tagged" field.
Ahh, parse_object() on the outer tag, when instantiating the in-core
obj, allocated an in-core object and that instance is already given
a type from the tag object and .taggeed member points at that
object, so it is not an "unknown" object (tag.c::parse_tag_buffer()).

Totally forgot about that one; thanks.
Do you have any suggestions for how this could be explained better? I
waffled on whether to add that paragraph to the commit message and when
I finally did, it seems it got a little bit too succinct.

I'm about to check out for today. Maybe in the morning I can think of
some clarification.

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