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

Re: [PATCH v2 4/4] bundle v3: the beginning

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 7, 2016, 19:23 UTC
Message-ID
<xmqqinxkpzur.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<CAP8UFD2t=2wJ=1U1ctMYNuMSejBYLh2yeLU7ZfP5Q6KLxUApjQ@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
Show 9 quoted lines
> Git can store its objects only in the form of loose objects in
> separate files or packed objects in a pack file.
> To be able to better handle some kind of objects, for example big
> blobs, it would be nice if Git could store its objects in other object
> databases (ODB).
>
> To do that, this patch series makes it possible to register commands,
> using "odb.<odbname>.command" config variables, to access external
> ODBs. Each specified command will then be called the following ways:

Hopefully it is done via a cheap RPC instead of forking/execing the command for each and every object lookup.

>   - "<command> have": the command should output the sha1, size and
> type of all the objects the external ODB contains, one object per
> line.

Why size and type at this point is needed by the clients? That is more expensive to compute than just a bare list of object names.

>   - "<command> get <sha1>": the command should then read from the
> external ODB the content of the object corresponding to <sha1> and
> output it on stdout.
The type and size should be given at this point.
>   - "<command> put <sha1> <size> <type>": the command should then read
> from stdin an object and store it in the external ODB.

Is ODB required to sanity check that <sha1> matches what the data hashes down to?

If this thing is primarily to offload large blobs, you might also want not "get" but "checkout <sha1> <path>" to bypass Git entirely, but I haven't thought it through.

Previous: Duy NguyenNext: Jeff King
Message 23 of 37 in “bundle: plug resource leak”
  1. 1/2 bundle: plug resource leakJunio C Hamano, Mar 1, 2016
  2. 2/2 bundle: keep a copy of bundle file name in the in-core bundle headerJunio C Hamano, Mar 1, 2016
  3. Jeff KingMar 2, 2016
  4. Junio C HamanoMar 2, 2016
  5. 0/4 "split bundle" previewJunio C Hamano, Mar 2, 2016
  6. 1/4 bundle doc: 'verify' is not about verifying the bundleJunio C Hamano, Mar 2, 2016
  7. 2/4 bundle: plug resource leakJunio C Hamano, Mar 2, 2016
  8. 3/4 bundle: keep a copy of bundle file name in the in-core bundle headerJunio C Hamano, Mar 2, 2016
  9. Jeff KingMar 2, 2016
  10. 4/4 bundle v3: the beginningJunio C Hamano, Mar 2, 2016
  11. Duy NguyenMar 3, 2016
  12. Junio C HamanoMar 3, 2016
  13. Duy NguyenMar 3, 2016
  14. Christian CouderMay 20, 2016
  15. Duy NguyenMay 31, 2016
  16. Christian CouderMay 31, 2016
  17. Duy NguyenJun 1, 2016
  18. Christian CouderJun 7, 2016
  19. Duy NguyenJun 1, 2016
  20. Christian CouderJun 7, 2016
  21. Mike HommeyJun 7, 2016
  22. Duy NguyenJun 7, 2016
  23. Junio C HamanoJun 7, 2016
  24. Jeff KingJun 7, 2016
  25. Duy NguyenJun 8, 2016
  26. Jeff KingJun 8, 2016
  27. Duy NguyenJun 9, 2016
  28. Jeff KingJun 9, 2016
  29. Junio C HamanoJun 8, 2016
  30. Jeff KingJun 8, 2016
  31. Jeff KingMay 31, 2016
  32. Jeff KingMay 31, 2016
  33. Christian CouderJun 7, 2016
  34. Jeff KingJun 7, 2016
  35. Jeff KingMar 2, 2016
  36. Junio C HamanoMar 2, 2016
  37. Jeff KingMar 2, 2016

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.