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

Re: [PATCH] bundle-uri: refresh packed_git if unbundle succeed

From
Patrick Steinhardt <ps@pks.im>
Date
May 17, 2024, 05:00 UTC
Message-ID
<ZkbkgT46mdNEhcf0@tanuki>
In-Reply-To
<pull.1730.git.1715742069966.gitgitgadget@gmail.com>
On Wed, May 15, 2024 at 03:01:09AM +0000, blanet via GitGitGadget wrote:
> From: Xing Xin <xingxin.xx@bytedance.com>
Long time no see :)
Show 48 quoted lines
> When using the bundle-uri mechanism with a bundle list containing
> multiple interrelated bundles, we encountered a bug where tips from
> downloaded bundles were not being discovered, resulting in rather slow
> clones. This was particularly problematic when employing the heuristic
> `creationTokens`.
> 
> And this is easy to reproduce. Suppose we have a repository with a
> single branch `main` pointing to commit `A`, firstly we create a base
> bundle with
> 
>   git bundle create base.bundle main
> 
> Then let's add a new commit `B` on top of `A`, so that an incremental
> bundle for `main` can be created with
> 
>   git bundle create incr.bundle A..main
> 
> Now we can generate a bundle list with the following content:
> 
>   [bundle]
>       version = 1
>       mode = all
>       heuristic = creationToken
> 
>   [bundle "base"]
>       uri = base.bundle
>       creationToken = 1
> 
>   [bundle "incr"]
>       uri = incr.bundle
>       creationToken = 2
> 
> A fresh clone with the bundle list above would give the expected
> `refs/bundles/main` pointing at `B` in new repository, in other words we
> already had everything locally from the bundles, but git would still
> download everything from server as if we got nothing.
> 
> So why the `refs/bundles/main` is not discovered? After some digging I
> found that:
> 
> 1. when unbundling a downloaded bundle, a `verify_bundle` is called to
>    check its prerequisites if any. The verify procedure would find oids
>    so `packed_git` is initialized.
> 
> 2. after unbundled all bundles, we would enter `do_fetch_pack_v2`,
>    during which `mark_complete_and_common_ref` and `mark_tips` would
>    find oids with `OBJECT_INFO_QUICK` flag set, so no new packs would be
>    enlisted if `packed_git` has already initialized in 1.
And I assume we do not want it to not use `OBJECT_INFO_QUICK`?
> Back to the example above, when unbunding `incr.bundle`, `base.pack` is
> enlisted to `packed_git` bacause of the prerequisites to verify. Then we
> can not find `B` for negotiation at a latter time bacause `B` exists in
> `incr.pack` which is not enlisted in `packed_git`.
Okay, the explanation feels sensible.
> This commit fixes this by adding a `reprepare_packed_git` call for every
> successfully unbundled bundle, which ensures to enlist all generated
> packs from bundle uri. And a set of negotiation related tests are added.

This makes me wonder though. Do we really need to call `reprepare_packed_git()` once for every bundle, or can't we instead call it once at the end once we have fetched all bundles? Reading on.

Show 30 quoted lines
> Signed-off-by: Xing Xin <xingxin.xx@bytedance.com>
> ---
>     bundle-uri: refresh packed_git if unbundle succeed
> 
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1730%2Fblanet%2Fxx%2Fbundle-uri-bug-using-bundle-list-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1730/blanet/xx/bundle-uri-bug-using-bundle-list-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1730
> 
>  bundle-uri.c                |   3 +
>  t/t5558-clone-bundle-uri.sh | 129 ++++++++++++++++++++++++++++++++++++
>  2 files changed, 132 insertions(+)
> 
> diff --git a/bundle-uri.c b/bundle-uri.c
> index ca32050a78f..2b9d36cfd8e 100644
> --- a/bundle-uri.c
> +++ b/bundle-uri.c
> @@ -7,6 +7,7 @@
>  #include "refs.h"
>  #include "run-command.h"
>  #include "hashmap.h"
> +#include "packfile.h"
>  #include "pkt-line.h"
>  #include "config.h"
>  #include "remote.h"
> @@ -376,6 +377,8 @@ static int unbundle_from_file(struct repository *r, const char *file)
>  			       VERIFY_BUNDLE_QUIET)))
>  		return 1;
>  
> +	reprepare_packed_git(r);
> +

So what's hidden here is that `unbundle_from_file()` will also try to access the bundle's refs right away. Surprisingly, we do so by calling `refs_update_ref()` with `REF_SKIP_OID_VERIFICATION`, which has the effect that we basically accept arbitrary object IDs here even if we do not know those. That's why we didn't have to `reprepare_packed_git()` before this change.

Now there are two conflicting thoughts here:
  - Either we can now drop `REF_SKIP_OID_VERIFICATION` as the object IDs
    should now be accessible.
  - Or we can avoid calling `reprepare_packed_git()` inside the loop and
    instead call it once after we have fetched all bundles.

The second one feels a bit like premature optimization to me. But the first item does feel like it could help us to catch broken bundles because we wouldn't end up creating refs for objects that neither we nor the bundle have.

Patrick
Previous: blanet via GitGitGadgetNext: Junio C Hamano
Message 2 of 66 in “bundle-uri: refresh packed_git if unbundle succeed”
  1. bundle-uri: refresh packed_git if unbundle succeedblanet via GitGitGadget, May 15, 2024
  2. Patrick SteinhardtMay 17, 2024
  3. Junio C HamanoMay 17, 2024
  4. Xing XinMay 20, 2024
  5. Junio C HamanoMay 20, 2024
  6. Xing XinMay 27, 2024
  7. Xing XinMay 20, 2024
  8. Karthik NayakMay 17, 2024
  9. Xing XinMay 20, 2024
  10. bundle-uri: verify oid before writing refsblanet via GitGitGadget, May 20, 2024
  11. Karthik NayakMay 21, 2024
  12. 0/4 object checking related additions and fixes for bundles in fetchesblanet via GitGitGadget, May 27, 2024
  13. 1/4 bundle-uri: verify oid before writing refsXing Xin via GitGitGadget, May 27, 2024
  14. Patrick SteinhardtMay 28, 2024
  15. Xing XinMay 30, 2024
  16. 2/4 unbundle: introduce unbundle_fsck_flags for fsckobjects handlingXing Xin via GitGitGadget, May 27, 2024
  17. Patrick SteinhardtMay 28, 2024
  18. Xing XinMay 29, 2024
  19. Patrick SteinhardtMay 30, 2024
  20. Xing XinMay 30, 2024
  21. 3/4 fetch-pack: expose fsckObjects configuration logicXing Xin via GitGitGadget, May 27, 2024
  22. Patrick SteinhardtMay 28, 2024
  23. Junio C HamanoMay 28, 2024
  24. Junio C HamanoMay 28, 2024
  25. Patrick SteinhardtMay 29, 2024
  26. Xing XinMay 30, 2024
  27. Patrick SteinhardtMay 29, 2024
  28. 4/4 unbundle: introduce new option UNBUNDLE_FSCK_FOLLOW_FETCHXing Xin via GitGitGadget, May 27, 2024
  29. Patrick SteinhardtMay 28, 2024
  30. Xing XinMay 30, 2024
  31. 0/4 object checking related additions and fixes for bundles in fetchesblanet via GitGitGadget, May 30, 2024
  32. 1/4 bundle-uri: verify oid before writing refsXing Xin via GitGitGadget, May 30, 2024
  33. 2/4 unbundle: extend verify_bundle_flags to support fsck-objectsXing Xin via GitGitGadget, May 30, 2024
  34. Patrick SteinhardtJun 6, 2024
  35. Xing XinJun 11, 2024
  36. 3/4 fetch-pack: expose fsckObjects configuration logicXing Xin via GitGitGadget, May 30, 2024
  37. 4/4 unbundle: introduce option VERIFY_BUNDLE_FSCK_FOLLOW_FETCHXing Xin via GitGitGadget, May 30, 2024
  38. Patrick SteinhardtJun 6, 2024
  39. Xing XinJun 11, 2024
  40. 0/4 object checking related additions and fixes for bundles in fetchesblanet via GitGitGadget, Jun 11, 2024
  41. 2/4 fetch-pack: expose fsckObjects configuration logicXing Xin via GitGitGadget, Jun 11, 2024
  42. 1/4 bundle-uri: verify oid before writing refsXing Xin via GitGitGadget, Jun 11, 2024
  43. 3/4 unbundle: extend options to support object verificationXing Xin via GitGitGadget, Jun 11, 2024
  44. Patrick SteinhardtJun 11, 2024
  45. Xing XinJun 11, 2024
  46. 4/4 unbundle: use VERIFY_BUNDLE_FSCK_FOLLOW_FETCH for fetchesXing Xin via GitGitGadget, Jun 11, 2024
  47. 0/3 object checking related additions and fixes for bundles in fetchesblanet via GitGitGadget, Jun 11, 2024
  48. 1/3 bundle-uri: verify oid before writing refsXing Xin via GitGitGadget, Jun 11, 2024
  49. Junio C HamanoJun 11, 2024
  50. Xing XinJun 17, 2024
  51. 2/3 fetch-pack: expose fsckObjects configuration logicXing Xin via GitGitGadget, Jun 11, 2024
  52. Junio C HamanoJun 11, 2024
  53. 3/3 unbundle: support object verification for fetchesXing Xin via GitGitGadget, Jun 11, 2024
  54. Junio C HamanoJun 11, 2024
  55. Xing XinJun 12, 2024
  56. Patrick SteinhardtJun 11, 2024
  57. 0/3 object checking related additions and fixes for bundles in fetchesblanet via GitGitGadget, Jun 17, 2024
  58. 1/3 bundle-uri: verify oid before writing refsXing Xin via GitGitGadget, Jun 17, 2024
  59. Junio C HamanoJun 18, 2024
  60. Xing XinJun 19, 2024
  61. 2/3 fetch-pack: expose fsckObjects configuration logicXing Xin via GitGitGadget, Jun 17, 2024
  62. 3/3 unbundle: extend object verification for fetchesXing Xin via GitGitGadget, Jun 17, 2024
  63. 0/3 object checking related additions and fixes for bundles in fetchesblanet via GitGitGadget, Jun 19, 2024
  64. 2/3 fetch-pack: expose fsckObjects configuration logicXing Xin via GitGitGadget, Jun 19, 2024
  65. 1/3 bundle-uri: verify oid before writing refsXing Xin via GitGitGadget, Jun 19, 2024
  66. 3/3 unbundle: extend object verification for fetchesXing Xin via GitGitGadget, Jun 19, 2024

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.