Junio C Hamano <gitster@xxxxxxxxx> writes:
> I haven't started using type=8 and upwards for anything yet, but because
> we have only one "future expansion" value left, I want us to be extremely
> careful in order to avoid painting us into a corner that we cannot get out
> of, so I am sending this out early for a preliminary review.
>
> Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
> ---
> cache.h | 3 ++-
> sha1_file.c | 36 ++++++++++++++++++++++++++++++++----
> 2 files changed, 34 insertions(+), 5 deletions(-)
>
> diff --git a/cache.h b/cache.h
> index 2e6ad36..b02139b 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -380,9 +380,10 @@ enum object_type {
> OBJ_TREE = 2,
> OBJ_BLOB = 3,
> OBJ_TAG = 4,
> - /* 5 for future expansion */
> + OBJ_EXT = 5, /* 5 for future expansion */
> OBJ_OFS_DELTA = 6,
> OBJ_REF_DELTA = 7,
> + OBJ_CAT_TREE = 8,
> OBJ_ANY,
> OBJ_MAX
> };
As people may be able to guess from the name, CAT_TREE is envisioned to
encode a large data (primarily of type "blob") by recording the object
name of a tree object and probably the total length, and would represent
the concatenation of all blobs contained in the tree object when the tree
is traversed in some fixed order (e.g. Avery's "bup split"). I am guessing
that the payload for CAT_TREE representation type will be:
- 20-byte object name for the top-level tree object;
- type of the basic object (commit, tree, blob, or tag) it represents,
even though it is unlikely that we would want to record such a large
commit or tag that needs CAT_TREE representation;
- the total length of the basic object it represents, even though it is
redundant (you could traverse and sum the sizes of blobs contained in
the tree object), it would help sha1_object_info() and friends. This
will be the "some size" I mentioned in the previous message for this
representation type.
We would probably add loose object representation for CAT_TREE, which may
look like:
"cattree" <size of this cat-tree in decimal> NUL
<basic object type> <size of the basic object> NUL
<object name of the top-level tree>
and would need to teach unpack_sha1_file() about it. One caveat is that
we would want to keep the "contents name the object" invariant, so even if
a large blob is expressed as a CAT_TREE, its object name must still be
what we would get by hashing '"blob" <size> NUL <payload>'.
A loose object file in "cattree" representation will not hash to the value
a naïve implementation would expect, and fsck_sha1() needs to be aware of
it. I haven't thought things through in this area.
Further work would involve (no way exhaustive, of course):
- Teach fsck and connectivity tools that objects that are reachable from
any object (even a blob) that is represented as a CAT_TREE are needed
and reachable by that object;
- Teach pack-objects that anything that is represented as a CAT_TREE does
not need to be deltified (the objects used as its representation would
go through the usual deltification rules);
- Teach unpack-objects to expand CAT_TREE representation into a "cattree"
loose object.
- Perhaps teach the attributes mechanism to lie to anybody who asks that
any object in CAT_TREE representation is a binary file to trigger the
"we do not unnecessarily look at binary" logic in "git diff" machinery.
- Teach fast-import to write out CAT_TREE representation. This is
probably the quickest and least-impact way to exploit existing support
for large files in index_fd().
- Update grep.c::grep_buffer() to take not <buf,size> but git_istream,
and rewrite builtin/grep.c::grep_sha1() to use streaming interface.
--
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