On Wed, Jan 13, 2021 at 12:06:03AM -0800, Junio C Hamano wrote:
> Taylor Blau <me@xxxxxxxxxxxx> writes:
>
> > In the next several patches, we will prepare for loading a reverse index
> > either in memory, or from a yet-to-be-introduced on-disk format. To do
>
> Does "load revindex in memory" (as opposed to "from on-disk file")
> mean the good old "read the forward index and make inverse map
> in-core", or something else?
Indeed, that's what it means. I've made that clearer in the patch
message by saying it explicitly.
> IOW, is "We will prepare a reverse index either by computing in
> memory from forward index, or loading from on-disk file" what we
> want to say here?
Yep.
> Without knowing what exactly "pack position", "offset" and "index
> position" refer to, the above three are almost impossible to grok.
> Can we have one paragraph description for each? Something along the
> lines of...
Yep, and I see later on in the thread that you want to discard this
suggestion since Peff has suggested similar changes in pack-revindex.h,
which I've applied.
> > Unlike some of the callers that used to access '->offset' and '->nr'
> > directly, the error checking around this call is somewhat more
> > robust. This is important since callers can pass an offset which
> > does not contain an object.
>
> Meaning "offset ought to point at the boundary between objects in
> the pack stream, and the API, unlike the direct access, makes sure
> that is the case"? That is a good thing.
Indeed, and I've called that out directly in the patch message to
highlight it.
> > diff --git a/pack-revindex.c b/pack-revindex.c
> > index ecdde39cf4..6d86a85208 100644
> > --- a/pack-revindex.c
> > +++ b/pack-revindex.c
> > @@ -203,3 +203,35 @@ struct revindex_entry *find_pack_revindex(struct packed_git *p, off_t ofs)
> >
> > return p->revindex + pos;
> > }
> > +
> > +int offset_to_pack_pos(struct packed_git *p, off_t ofs, uint32_t *pos)
> > +{
> > + int ret;
> > +
> > + if (load_pack_revindex(p) < 0)
> > + return -1;
> > +
> > + ret = find_revindex_position(p, ofs);
> > + if (ret < 0)
> > + return -1;
>
> Why not "return ret"? We know that find_revindex_position() would
> signal an error by returning -1, but is there a reason why we want
> to prevent it from returning richer errors in the future?
No reason, I've changed it to 'return ret' instead.
> > + *pos = ret;
>
> The untold assumption is that uint32_t can fit the maximum returned
> value from find_revindex_position() and "signed int" can also big
> enough. I guess it is OK to be limited to up-to 2 billion objects
> on 32-bit systems.
Indeed, and that is fixed in a later on patch. I'll make sure to call it
out there.
> > + return 0;
> > +}
> > +
> > +uint32_t pack_pos_to_index(struct packed_git *p, uint32_t pos)
> > +{
> > + if (!p->revindex)
> > + BUG("pack_pos_to_index: reverse index not yet loaded");
>
> The previous function lazy loaded the revindex, but this one and the
> next one refuses to work without revindex. Intended?
Yes, and discussed a little bit more here [1]. Obviously that discussion
doesn't do any good to those reading the git log in the future, so I've
summarized the important detail (that some callers are equipped to deal
with errors but others aren't) in the patch.
> > + if (pos >= p->num_objects)
> > + BUG("pack_pos_to_index: out-of-bounds object at %"PRIu32, pos);
>
> Personally I find it easier to place items on a single line in an
> ascending order of magnitude, i.e.
>
> if (p->num_objects <= pos)
> BUG("...");
More readable, thanks.
> The assertion requires pos to be strictly lower than p->num_objects,
> which is in line with how we usually count elements of an array of
> size p->num_objects, but the next one allows pos == p->num_objects;
> intended?
>
> p->revindex[] is an array of two-member struct, so if an element of
> the array is invalid for its .nr member here because pos is exactly
> at p->num_objects, I would imagine it is also invalid for its .offset
> member, too, no?
>
> Ah, perhaps the "offset beyond the end of the pack positions" is a
> sentinel element to give the in-pack-stream size of the object at
> the last pack position? If that is the case, it deserves a comment,
> I would think.
Exactly. I added a detail about that in the patch, too.
Thanks,
Taylor
[1]: https://lore.kernel.org/git/X%2F3ODgaa9wr65M09@nand.local/
