[GSOC][RFC] Draft Proposal: Complete and extend the remote-object-info command for git cat-file

[Deveshi Dwivedi <deveshigurgaon@gmail.com>]

Hi! I would be grateful to get feedback on my proposal draft for GSoC
2026. Thank you very much!
-----------------------------------------------------------------------

Complete and extend the remote-object-info command for git cat-file

-----------------------------------------------------------------------

Personal Information

Name: Deveshi Dwivedi
Email: deveshigurgaon@gmail.com
GitHub: https://github.com/deveshidwivedi
Time Zone: UTC +5:30 (IST)
Education: Final year, IIIT Jabalpur
Blog: https://deveshidwivedi.github.io

-----------------------------------------------------------------------

Past experience with Open Source

I have been contributing to open source for the past few years. My
first contribution was during my second year of college. Since then I
have tried contributing to different projects to get better at
navigating unfamiliar codebases and understanding how real-world
projects are maintained. Some of my contributions include:

- https://github.com/processing/p5.js-web-editor/pull/3492

- https://github.com/neovim/neovim/pull/33235

- https://github.com/kube-vip/kube-vip/pull/1087

- https://github.com/WasmEdge/WasmEdge/pull/3963

- https://github.com/openfoodfacts/openfoodfacts-server/pull/10037

- https://github.com/openfoodfacts/openfoodfacts-server/pull/9967

- https://github.com/processing/p5.js/pull/6761

- https://github.com/processing/p5.js/pull/6669

I was also grateful to be an LFX mentee in Summer 2024 under the Open
Mainframe Project. During the program I worked on building a new
frontend for the Software Discovery Tool and integrating it with the
backend to make the tool easier to use.

-----------------------------------------------------------------------

My contributions so far

*t5403: use test_path_is_file instead of test -f
*Mailing list: https://lore.kernel.org/git/20251229185737.2328-1-deveshigurgaon@gmail.com/
*Status: merged in 'master'
*Description: Replace test -f with test_path_is_file helper in
post-checkout hook test for better failure diagnostics.

*t5403: improve post-checkout hook testing
*Mailing list: https://lore.kernel.org/git/20260112163643.231-1-deveshigurgaon@gmail.com/
*Status: merged in 'master'
*Description: Introduce check_post_checkout helper to eliminate
repetitive hook validation patterns, then switch to test_cmp for
clearer argument mismatch diagnostics.

*t1006: fix %(rest) test for object names with whitespace
*Mailing list: https://lore.kernel.org/git/20260219152407.12160-1-deveshigurgaon@gmail.com/
*Status: dropped
*Description: Submitted a patch to address a FIXME in t1006 around
%(rest) behavior with whitespace in object names. Junio explained that
whitespace-as-delimiter is documented behavior for %(rest), not a bug,
and Victoria clarified the FIXME was intentionally documenting a known
limitation, not requesting a fix. This taught me to read test comments
in their full historical context rather than treating them as isolated
tasks. It also introduced me to t1006-cat-file.sh in depth, which is
directly relevant to this project.

*avoid unnecessary strbuf_split*() and strbuf-by-value usage
*Mailing list: https://lore.kernel.org/git/20260311173336.8395-1-deveshigurgaon@gmail.com/
*Status:Will merge to 'master'
*Description: Eliminate inefficient strbuf_split_str() in combine
filter parsing by using direct string traversal with strchrnul(), and
convert write_worktree_linking_files() to accept path strings instead
of strbuf-by-value parameters.

*coccinelle: detect and fix strbuf-by-value parameters
*Mailing list: https://lore.kernel.org/git/20260315094445.19849-1-deveshigurgaon@gmail.com/
*Status: queued
*Description: Add Coccinelle semantic patch to automatically detect
functions taking struct strbuf by value, transforming them to pointer
parameters and fix the remaining instance in stash.c.

-----------------------------------------------------------------------

Project Overview

This project completes and extends the remote-object-info subcommand
for git cat-file --batch-command, which allows clients to request
object metadata from a remote without downloading full object
contents.

Goal 1: Rebase and finalize Eric Ju's v11 patch series [1], address
the remaining review feedback, and get it merged.
Goal 2: Add %(objecttype) support to the object-info protocol, end-to-end.

-----------------------------------------------------------------------

Proposed Solution

----------

Goal 1: Complete v11 Series

----------

Pre-GSoC Analysis:

I rebased Eric Ju's v11 series [1] onto the current master. There were
conflicts in t/t1006-cat-file.sh, fetch-pack.c, Makefile and
object-file.c. After resolving those and building, I ran the test
suite.

While running t/t1017-cat-file-remote-object-info.sh [2], the first
test failed with "ambiguous redirect". '$daemon_parent' expands to the
trash directory path which contains a space and the redirect is not
quoted:

echo_without_newline "$hello_content" > $daemon_parent/hello

The shell splits on the space and does not know which file to redirect
to. I grepped for other unquoted uses and found the same problem with
$HTTPD_DOCUMENT_ROOT_PATH/http_parent/hello in the http test section.
This is fixed once we quote both the instances.

In review of Calvin Wan's initial remote-object-info implementation
[3], Jonathan Tan observed that the remote-object-info state
is currently stored in static globals rather than in the shared
command data structure. This approach makes it difficult to support
mixing commands in a batch session. The v11 series addressed most of
this by restructuring the code so that remote-object-info now goes
through the same expand_data path used by info. However, one instance
of shared state mutation still remains.

In get_remote_info(), when no explicit format is given, currently the code does:

if (!opt->format)
    opt->format = "%(objectname) %(objectsize)";

The problem is that opt->format is shared across all commands in the
batch session. batch_objects() creates a single expand_data structure,
which every command uses. Mutating opt->format here permanently
replaces the original NULL value.

Fix: Instead of modifying the shared state,  we can use a local
variable in parse_cmd_remote_object_info():

const char *remote_format = opt->format
    ? opt->format
    : "%(objectname) %(objectsize)";

and pass remote_format to get_remote_info() for validation. This fix
is needed regardless of Goal 2. Even when the values happen to match,
mutating shared state from a command handler is incorrect. Once
%(objecttype) support is added, the special-case default disappears
entirely, and both local and remote commands can simply use
DEFAULT_FORMAT.

----------

Review Feedback Analysis

Below are the main issues raised during the v11 review of the
remote-object-info patch series and how I plan to address them:

Issue 1: Format Validation Segfault [4]
The current validation uses a strstr() check to ensure that the format
contains %(objectsize). This is not sufficient. A format like:

%(objecttype) %(objectsize)

passes the check but later causes a segfault.
The crash occurs in expand_atom():

strbuf_addstr(sb, type_name(data->type));

The call chain looks like this:

batch_objects_command()
  → parse_cmd_remote_object_info()
    → get_remote_info()           ← validation belongs here
      → transport_fetch_refs()
    → batch_object_write()
      → expand_format()
        → expand_atom()           ← segfault here

The problem is that data->type may never be initialized. When it
remains OBJ_NONE (0), type_name(0) returns NULL because
object_type_strings[0] is NULL. That NULL is then passed to
strbuf_addstr(), which dereferences it and segfaults.
Jeff King pointed this out during review [4]. While experimenting with
the feature, he tried:

git cat-file --batch-command='%(objecttype) %(objectsize)'

and feeding it a remote-object-info request, which triggered the
crash. I was able to reproduce the same behavior locally using a
simple client/server setup and a blob from a test repository.

Fix: Instead of relying on a strstr() check, the validation should
determine which atoms were actually requested by the format. During
the mark-query phase, expand_format() records requested atoms by
populating the corresponding fields in data.info. After this stage we
can inspect those fields to see exactly which atoms were requested.

If the format asks for something remote-object-info cannot provide,
the command should exit with an error that names the unsupported atom.
The format is defined when the batch session starts, so requesting an
unsupported atom is a configuration error rather than a per-object
condition. Returning empty output would be misleading, since a caller
would not be able to tell whether the object actually lacks that
attribute or the protocol simply does not support it. Failing early
with a clear error avoids silently producing incorrect results.

Implementing this validation requires passing the expand_data instance
down to get_remote_info(). In v11 the function currently has the
signature:

static int get_remote_info(struct batch_options *opt, int argc, const
char **argv)

For this check to work, the expand_data pointer needs to be threaded
through from parse_cmd_remote_object_info(). This ends up being the
same signature change required for the format-mutation fix described
earlier, so both fixes can share the same small refactor.

As an additional safety measure, a defensive guard can be added in
expand_atom() so that it cannot segfault even if validation is
bypassed in a future code path.

Finally, the EXPAND_DATA_INIT macro currently initializes only .mode =
S_IFINVALID. It should also initialize .type = OBJ_BAD. Since OBJ_BAD
is -1, outside the bounds of the object_type_strings array,
type_name() will return NULL, which is then safely handled by the
guard above.

Issue 2: Misleading Input Overflow Error [5]

The current overflow check reports that the command contains too many
objects, but that may not be the real cause. For example, a very long
repository URL could exceed the line length limit and trigger the same
error. Junio pointed this out in his review [5].

Fix: We can handle this with two separate validation steps.

First,we can check the line length before parsing and report any
overflow accurately. After parsing, we can validate the number of
requested objects. Malformed quoting should also be caught during
parsing. Separating these checks ensures that error messages point to
the actual problem, rather than incorrectly blaming too many objects.

Issue 3: Code Style and State Management

The patch series also introduces a few style inconsistencies that
should be cleaned up:
- multi-line comment formatting
- missing blank lines between #define groups
- long macro definitions
- mixing size_t and int for loop counters

In addition, parse_cmd_remote_object_info() should reset all fields in
expand_data that it modifies before returning. The v11 implementation
already resets data->skip_object_info = 0 on both normal and error
paths, but it does not reset data->type or data->size. Resetting these
fields avoids leaking stale remote state into subsequent commands.

data->skip_object_info = 0; (already in v11)
data->type = OBJ_BAD;
data->size = 0;

Without these resets, a batch session that runs remote-object-info
followed by a local info command could produce incorrect output. If
odb_read_object_info_extended() fails for the local object, the
previously populated remote values may still be present in data,
causing stale data to be printed. It is also important that the
data->skip_object_info = 0 reset happens even on the goto cleanup
error path so that the state is fully restored before returning.

New tests to be added for v12:
- %(objecttype) %(objectsize) format: command dies cleanly instead of
segfaulting
- %(objecttype) alone: command dies with a clear error
- %(objectname) only: works without requesting size
- Mixed remote-object-info and info commands in batch mode: both use
the correct default formats (this also catches the format-mutation
issue)

----------
Goal 2: Add support for %(objecttype)
----------
Server Side

struct requested_info in protocol-caps.c is extended to include
unsigned type : 1, alongside the existing unsigned size : 1. The
capability parser in cap_object_info() is updated to recognize type
requests using the same pattern that is already used for size. The
server-side response logic in send_info() is then updated to include
the type when it has been requested.

One useful optimization here is that odb_read_object_info() already
provides the object type as its return value, while the object size is
returned through an output parameter. The current implementation in
send_info() calls this function but discards the return value after
checking whether it is negative. When both size and type are
requested, we can obtain both pieces of information from a single
call. If only type is requested, the call simply passes NULL for the
sizep parameter.

For loose objects, both the type and size are stored in the same
object header ("<type> <size>\0"). For packed objects, the type is
already in the pack entry header, so retrieving it is free.

When sending responses, send_info() includes both size and type in the
headers if requested. Each object line looks like:

<oid> <size> <type>

If the server cannot resolve an attribute, that field is left blank.
Behavior for missing values remains consistent with existing handling.

On the server side, object_info_advertise() in serve.c no longer marks
its struct strbuf *value as UNUSED and now populates it with "size
type". This means the server advertises:

object-info=size type

during capability negotiation. Older clients ignore the value string
per protocol v2 rules, and the server_supports_v2("object-info") check
continues to work, so backward compatibility is maintained.

----------

Client Transport

Before requesting type, the client checks whether the server supports
it using server_supports_feature("object-info", "type", 0). This looks
at the capability value and parses it with parse_feature_request(). If
the server advertises only object-info=size, the check returns false
for type. In that case, if the format requires %(objecttype), the
client exits with a clear error. When building the request,
unsorted_string_list_has_string() is used instead of strstr() to avoid
substring matches.

On the response side, the client keeps track of column positions using
size_index and type_index, both initialized to -1. The attribute
headers sent by the server determine which columns appear and in what
order. The data lines are then parsed using those indices with bounds
checks. Since column 0 is always the OID, the indices use a +1 offset.
For example: in <oid> 1234 blob, column 1 contains the size and column
2 contains the type. If fewer columns are returned than expected, the
bounds checks prevent out-of-range access.

----------

Memory: I will allocate typep per OID the same way v11 already does
for sizep; free_object_info_contents() handles cleanup.

----------

cat-file integration

In get_remote_info(), the format string determines which attributes
are requested from the server. Previously, if %(objectsize) appeared
in the format, "size" was added to object_info_options. With this
change, %(objecttype) similarly adds "type".

Since %(objecttype) is now supported, the earlier allow-list
validation that rejected data->info.typep is removed.

Supporting %(objecttype) also allows the removal of the special-case
default format in get_remote_info(). Both local and remote commands
can now use DEFAULT_FORMAT (%(objectname) %(objecttype)
%(objectsize)), eliminating the previous mismatch in default output.

----------

Backward Compatibility:

A new client with a new server supports both size and type. With a new
client and an old server, server_supports_feature() returns false for
type, and the client exits with a clear error if the format requests
%(objecttype). Size-only requests still work. Old clients work with
any server. They ignore the new type capability and only request the
attributes they understand, so existing workflows continue to work as
before.

----------

Testing for Goal 2

Server-side (t/t5701-git-serve.sh):

Server advertises object-info=size type
Correct type strings for all four object types
Combined size + type and type-only requests

Client-side (t/t1017-cat-file-remote-object-info.sh):

%(objecttype) across git://, file://, http://
Default format includes type after unification
Server that only supports size: clean error for %(objecttype)
Mixed local + remote in buffer mode (state isolation)

----------

Stretch Goals (if time permits)

If Goal 1 and Goal 2 land ahead of schedule, %(objectsize:disk) could
be explored. The server infrastructure already exists via
odb_read_object_info_extended() and the implementation pattern is
identical to %(objecttype). %(deltabase) is a similar extension. Both
depend on server pack format rather than intrinsic object properties,
so either would need mailing list consensus before proceeding.

-----------------------------------------------------------------------

Project Timeline

I have intentionally allocated slightly longer phase intervals to
provide a buffer. In practice, each task may take less time, but this
ensures there is room to handle unexpected delays without affecting
the overall schedule.

Pre-GSoC (Until May 1):
- Continue exploring the codebase.
- Stay engaged with the community and follow discussions.

Community Bonding (May 1 - 25):
- Study the codebase and internals in more depth.
- Review all v11 feedback threads.
- Identify rebase conflicts.
- Discuss protocol design with mentors on the mailing list.

Phase 1: Rebase and Fix (May 26 - Jun 15):
- Rebase v11 onto master.
- Fix all bugs: format validation, input validation, format mutation,
state cleanup, code style, test quoting.
- Add new tests.
- Send v12 to the mailing list.

Phase 2 (Jun 16 - Jul 6):
- Iterate on v12 review feedback.
- Begin server-side type implementation.
- Add server tests, send server patches.

Midterm (Jul 10):
- Goal 1 in final review or merged.
- Server patches posted.

Phase 3: Client and Integration (Jul 14 - Aug 10):
- Iterate on server patches.
- Implement client transport and cat-file integration.

Phase 4: Final (Aug 11 - 24):
- Final review iteration.
- Buffer for unexpected issues.
- Ensure all patches are in the review pipeline.

Final Evaluation (Aug 25 - 31):
- Address any remaining review feedback.

-----------------------------------------------------------------------

Availability

The project size is 350 hours (medium). I plan to dedicate around 35
hours per week during the 12-week coding period to work on the
project. I do not anticipate any major conflicts during this time and
will be able to stay actively engaged with development and
discussions.

-----------------------------------------------------------------------

Post GSoC

I would like to stay active in the Git community even after GSoC.
There is still a lot for me to learn from the project and the
community, and I hope to continue contributing and improving my
understanding of Git’s internals.

-----------------------------------------------------------------------

References

[1] https://lore.kernel.org/git/20250221190451.12536-1-eric.peijian@gmail.com/

[2] https://lore.kernel.org/git/20240628190503.67389-7-eric.peijian@gmail.com/

[3] https://lore.kernel.org/git/20220504212738.162853-1-jonathantanmy@google.com/

[4] https://lore.kernel.org/git/20240628190503.67389-1-eric.peijian@gmail.com/t/#md20501dc269cc38ac1ac8cf7599281b937b651a0

[5] https://lore.kernel.org/git/20240628190503.67389-1-eric.peijian@gmail.com/t/#mbe53f476d6cd32633277c28f17f8b6a59316b1db

--
Thank you,
Deveshi