git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] index-pack: prefetch missing REF_DELTA bases

From
JTJonathan Tan <jonathantanmy@google.com>
Date
May 16, 2019, 23:15 UTC
Message-ID
<20190516231509.253998-1-jonathantanmy@google.com>
In-Reply-To
<20190516214257.GD10787@sigill.intra.peff.net>
Show 15 quoted lines
> > > Right, REF_DELTA is definitely correctly handled currently, and I don't
> > > think that would break with your patch. It's just that your patch would
> > > introduce a bunch of extra traffic as we request bases separately that
> > > are already in the pack.
> > 
> > Ah...I see. For this problem, I think that it can be solved with the
> > "if (objects[d->obj_no].real_type != OBJ_REF_DELTA)" check that the
> > existing code uses before calling read_object(). I'll include this in
> > the next reroll if any other issue comes up.
> 
> I'm confused about this. Aren't we pre-fetching before we've actually
> resolved deltas? The base could be in the pack as a true base, and we
> might have seen it already then. But it could itself be a delta, and we
> wouldn't know we have it until we resolve it (this gets into the
> lucky/unlucky ordering thing).

resolve_deltas(), invoked before any new code introduced in this patch, has this comment:

Show 8 quoted lines
> /*
>  * Second pass:
>  * - for all non-delta objects, look if it is used as a base for
>  *   deltas;
>  * - if used as a base, uncompress the object and apply all deltas,
>  *   recursively checking if the resulting object is used as a base
>  *   for some more deltas.
>  */
I haven't seen any code that contradicts this comment. And looking at
the code, for each non-delta object, I think that all deltas are checked
- regardless of whether they appear before or after that non-delta
object. (find_ref_delta() does a binary search from 0 to
nr_ref_deltas, calculated in parse_pack_objects() which happens before
any resolution of deltas.)

And find_unresolved_deltas_1() (called from resolve_deltas() indirectly) sets the real_type when it resolves a delta, as far as I can tell.

So there is more than one "resolve deltas" step - resolve_deltas() and then fix_unresolved_deltas(). The pre-fetching happens only during the latter.

Previous: Jeff KingNext: Jeff King
Message 16 of 26 in “Partial clone fix: handling received REF_DELTA”
  1. 0/2 Partial clone fix: handling received REF_DELTAJonathan Tan, May 14, 2019
  2. 1/2 t5616: refactor packfile replacementJonathan Tan, May 14, 2019
  3. Johannes SchindelinMay 15, 2019
  4. Jonathan TanMay 15, 2019
  5. 2/2 index-pack: prefetch missing REF_DELTA basesJonathan Tan, May 14, 2019
  6. Johannes SchindelinMay 15, 2019
  7. Jonathan TanMay 15, 2019
  8. Johannes SchindelinMay 17, 2019
  9. Jeff KingMay 15, 2019
  10. Junio C HamanoMay 16, 2019
  11. Jeff KingMay 16, 2019
  12. Jonathan TanMay 16, 2019
  13. Jeff KingMay 16, 2019
  14. Jonathan TanMay 16, 2019
  15. Jeff KingMay 16, 2019
  16. Jonathan TanMay 16, 2019
  17. Jeff KingMay 17, 2019
  18. Jeff KingMay 17, 2019
  19. Jeff KingMay 17, 2019
  20. Jeff KingMay 17, 2019
  21. Duy NguyenMay 17, 2019
  22. Jeff KingMay 17, 2019
  23. Duy NguyenMay 18, 2019
  24. Nicolas PitreMay 20, 2019
  25. Jeff KingMay 21, 2019
  26. Jonathan NiederJun 3, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.