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

Re: Using bitmaps to accelerate fetch and clone

From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date
Sep 28, 2012, 01:37 UTC
Message-ID
<CACsJy8AbVi-uR2-5Ndz3cTAzz_=xahOSpTBGOsB2XdYTsYtG6w@mail.gmail.com>
In-Reply-To
<CAJo=hJt0PdpDT5ROUSfZ80Zh2ep=r5Sg1BS=v7Ve-djydHhp-w@mail.gmail.com>
On Thu, Sep 27, 2012 at 9:33 PM, Shawn Pearce <spearce@spearce.org> wrote:
Show 21 quoted lines
>> I'd like to see some sort of extension mechanism like in
>> $GIT_DIR/index, so that we don't have to increase pack index version
>> often.
>
> This might be worthwhile. I dislike the way $GIT_DIR/index encodes
> extensions. Forcing an extension to fully materialize itself to
> determine its length so the length can be placed before the data is
> painful to work with when writing the file out to disk. I would prefer
> writing an index catalog at the trailer of the file. We already
> require random access to the index file, so its possible for a reader
> to read a fixed size trailer record that has the 2 SHA-1s we normally
> end an index with, and an extension catalog footer that has a length
> and CRC-32 of the catalog. The catalog would immediately appear before
> the footer, so a reader can find the start of the extension catalog by
> subtracting from the end of the file the catalog length and the file
> footer and catalog footer lengths. The catalog can then supply a
> starting offset for each extension section, and writers don't need to
> predict in advance how much data they need to store. Readers trying to
> use extensions aren't really hurt, Git already randomly seeks to read
> the tail of an index file to compare the pack SHA-1 before assuming
> the index is valid.

Yeah, that's exactly what I had in mind. But perhaps a separate file (or files?) may be better. On that point, should all extensions be in one new extra file, or one extension per file? I prefer all extensions in one file, so we only need a single additional stat() for extension check instead of probing for the entire pack-XXX.* range. In that case, the catalog trailer idea still applies.

-- 
Duy
Previous: Shawn PearceNext: Jeff King
Message 4 of 20 in “Using bitmaps to accelerate fetch and clone”
  1. Shawn PearceSep 27, 2012
  2. Nguyen Thai Ngoc DuySep 27, 2012
  3. Shawn PearceSep 27, 2012
  4. Nguyen Thai Ngoc DuySep 28, 2012
  5. Jeff KingSep 27, 2012
  6. Shawn PearceSep 27, 2012
  7. Jeff KingSep 27, 2012
  8. Shawn PearceSep 27, 2012
  9. Jeff KingSep 27, 2012
  10. Jeff KingSep 27, 2012
  11. Junio C HamanoSep 27, 2012
  12. Jeff KingSep 27, 2012
  13. David Michael BarrSep 27, 2012
  14. Nguyen Thai Ngoc DuySep 28, 2012
  15. Nguyen Thai Ngoc DuySep 28, 2012
  16. Shawn PearceOct 1, 2012
  17. Nguyen Thai Ngoc DuyOct 1, 2012
  18. Shawn PearceOct 1, 2012
  19. Nguyen Thai Ngoc DuyOct 1, 2012
  20. Shawn PearceOct 2, 2012

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.