Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes:
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html