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

Re: What's cooking in git.git (May 2011, #06; Fri, 13)

From
Junio C Hamano <gitster@pobox.com>
Date
May 14, 2011, 17:37 UTC
Message-ID
<7vsjsh5gjw.fsf@alter.siamese.dyndns.org>
In-Reply-To
<BANLkTimHdZ_9PUg509Yb7g2Oyp3qk0cKdA@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 5 quoted lines
>> The counterpart to jc/bigfile to cover the write-out codepath. This does
>> not yet have "read directly from pack or loose object without slurping the
>> whole thing in memory" yet, which is still work in progress.
>
> You haven't sent this to git@vger, or it failed to deliver to me.
That is because it is still in flux and not ready for public viewing yet.
> Anyway, do you plan to extend sha1_object_info_extended() further...

By definition a topic that is still in flux does not have concrete plans for everything. I haven't gone far enough to be interested in adding a support for something the other parts of the system do not support.

It is a lot more important to support the data types and representations that are supported by the other parts of the system already, and fill the missing parts. "git add" will learn to handle huge blobs natively in the jc/bigfile topic. This topic is about handling huge blobs in the checkout codepath. Without it, the system is useless if you cannot check them out even if you can add them.

The sending side of "git push" (aka "send-pack") and "git fetch" (aka "upload-pack") should also be Ok because pack-objects has known to handle large blob in a pack by copying the bits straight without re-deltifying.

I however think the receiving end still wants to hold everything in core. It would be the natural next thing to fix around this area before doing anything else. If somebody is interested, look at the receiving end ("index-pack" and "unpack-objects") while I am still busy in this topic.

Multiple people working on separate independent areas who share a reasonably narrow common agenda tend to speed up the development. At the very end of Linus era of git, after he wrote pack-objects, he worked on the object transfer protocols and unpack-objects, and I took the local use of the data in packed objects in read_sha1_file() codepath. There weren't much overlap or conflicting design decision in our works, and it turned out great. The common agenda in this case was to make the new object representation (i.e. packs) useful throughout the system.

On the other hand, multiple people working in a similar area with different agenda tend to step on each other's toes.

Previous: Nguyen Thai Ngoc DuyNext: Nguyen Thai Ngoc Duy
Message 3 of 12 in “What's cooking in git.git (May 2011, #06; Fri, 13)”
  1. Junio C HamanoMay 13, 2011
  2. Nguyen Thai Ngoc DuyMay 14, 2011
  3. Junio C HamanoMay 14, 2011
  4. Nguyen Thai Ngoc DuyMay 15, 2011
  5. Jens LehmannMay 15, 2011
  6. Junio C HamanoMay 15, 2011
  7. Teach read-tree the -n|--dry-run optionJens Lehmann, May 17, 2011
  8. Jens LehmannMay 17, 2011
  9. Junio C HamanoMay 17, 2011
  10. unpack-trees: add check_worktree flag to enable dry-run functionalityJens Lehmann, May 19, 2011
  11. Junio C HamanoMay 19, 2011
  12. Jens LehmannMay 19, 2011

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.