Git development
 help / color / mirror / Atom feed
From: Pablo Sabater <pabloosabaterr@gmail.com>
To: git@vger.kernel.org
Cc: chandrapratap3519@gmail.com, karthik.188@gmail.com,
	gitster@pobox.com,  peff@peff.net,
	Pablo Sabater <pabloosabaterr@gmail.com>
Subject: [PATCH GSoC v3 0/8] cat-file: extend remote-object-info to support %(objecttype)
Date: Mon, 03 Aug 2026 16:39:27 +0200	[thread overview]
Message-ID: <20260803-objecttype-support-v3-0-7176fecf7950@gmail.com> (raw)
In-Reply-To: <20260725-objecttype-support-v1-0-2d4ca3bbabf1@gmail.com>

Neither the client nor the server knows how to handle type. This series
continues the work for git cat-file --batch-command extending
remote-object-info to support "%(objecttype)" end to end. It is based on
its predecessor series "cat-file: add remote-object-info to
batch-command" [1].

Type is the last property that is identical on the server and on the
client once fetched.

Whether to support more metadata such as:

- objectsize:disk
- deltabase
- objectmode (needs context)

should be discussed, unlike size and type, the rest depend on how things
are packed on the server and on what the client already has, so they
cannot reliably match local once fetched. IMO they are not worth
supporting, I can't find a use case for them.

To add a new placeholder, follow the steps in this series and add its
wants_* flag to struct fetch_object_info_results.

Patches 1-4 are preparatory. They don't change what the command does:
- 1/8 is a test cleanup.
- 2/8 fixes a possible bug in case of a truncated response.
- 3/8 and 4/8 refactor how the object data is stored and handled. The
  why about this refactor comes from [2].

Patches 5-8 are the actual objecttype support:
- 5/8 teaches the server to answer type.
- 6/8 teaches the client to parse it.
- 7/8 advertises the capability so the client can start asking it.
- 8/8 unifies the default format.

Note that wants_type is added in 4/8 while the types array only appears
in 6/8. This is intentional, it shows that asking for an attribute the
server does not advertise just outputs an empty string, as it would for
any other placeholder.

Based-on: <20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com>

Github CI: https://github.com/pabloosabaterr/git/actions/runs/30821717187

[1]: https://lore.kernel.org/git/20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com/
[2]: https://lore.kernel.org/git/xmqqzez67yg1.fsf@gitster.g/

Signed-off-by: Pablo Sabater <pabloosabaterr@gmail.com>
---
Changes in v3:
- 1/8 (was 2/6): reword the commit message to explain that "wc -c | xargs"
  only strips the padding some platforms add.
- New 2/8: die if the server sends fewer object-info lines than
  requested OIDs. Preexisting bug.
- New 3/8: drop struct object_info_args and pass its members directly to
  fetch_object_info().
- New 4/8: replace struct object_info with struct
  fetch_object_info_results to hold the results. This also drops the
  object_info_options string list, remote_atom_map[] and
  free_object_info_contents().
- Dropped 1/6, which replaced the hardcoded "size" in
  send_object_info_request() with a loop over object_info_options, as
  that list no longer reaches it.
- 6/8: follows the new result struct, so it only adds the type array.
- 7/8: quote $hello_type in the test.
- Link to v2: https://lore.kernel.org/git/20260731-objecttype-support-v2-0-af577461ed57@gmail.com/

Changes in v2:
- Changed t5701 test to use test_file_size.
- Changed the for loop to use for_each_string_list_item().
- Moved "fetch-object-info: request all supported options dynamically"
  patch to be the first one as it is prep patch.
- Typos and nits.
- Restored the test mixing info and remote-object-info, adapted to the
  unified format.
- Link to v1: https://lore.kernel.org/git/20260725-objecttype-support-v1-0-2d4ca3bbabf1@gmail.com/

---
Pablo Sabater (8):
      t5701: use test_file_size() to get the size of a file
      fetch-object-info: detect truncated server responses
      fetch-object-info: pass arguments directly instead of a struct
      fetch-object-info: use dedicated struct for the results
      protocol-caps: add type support to object-info
      fetch-object-info: parse type from server response
      serve: advertise type capability
      cat-file: unify default format

 Documentation/git-cat-file.adoc        |  17 ++--
 Documentation/gitprotocol-v2.adoc      |  18 ++++-
 builtin/cat-file.c                     |  69 +++++-----------
 fetch-object-info.c                    | 141 +++++++++++++++++++++------------
 fetch-object-info.h                    |  37 ++++++---
 object-file.c                          |  10 ---
 odb.h                                  |   3 -
 protocol-caps.c                        |  21 ++++-
 serve.c                                |   4 +-
 t/t1017-cat-file-remote-object-info.sh |  78 +++++++++++-------
 t/t5701-git-serve.sh                   |  41 +++++++++-
 transport.c                            |  12 ++-
 transport.h                            |   5 +-
 13 files changed, 271 insertions(+), 185 deletions(-)

Range-diff versus v2:

1:  3fb0ea6af4 < -:  ---------- fetch-object-info: request all supported options dynamically
2:  641911ed87 < -:  ---------- t5701: use the test_file_size() helper
-:  ---------- > 1:  84810a5500 t5701: use test_file_size() to get the size of a file
-:  ---------- > 2:  16e2735bd5 fetch-object-info: detect truncated server responses
-:  ---------- > 3:  f42882ee03 fetch-object-info: pass arguments directly instead of a struct
-:  ---------- > 4:  3053d33534 fetch-object-info: use dedicated struct for the results
3:  a77e38e171 ! 5:  1331fab35f protocol-caps: add type support to object-info
    @@ t/t5701-git-serve.sh: test_expect_success 'basics of object-info' '
     +test_expect_success 'object-info supports type' '
     +	test_config transfer.advertiseObjectInfo true &&
     +
    ++	two_oid=$(git rev-parse two:two.t) &&
    ++	two_size=$(test_file_size two.t) &&
    ++
     +	test-tool pkt-line pack >in <<-EOF &&
     +	command=object-info
     +	object-format=$(test_oid algo)
     +	0001
     +	size
     +	type
    -+	oid $(git rev-parse two:two.t)
    -+	oid $(git rev-parse two:two.t)
    ++	oid $two_oid
    ++	oid $two_oid
     +	0000
     +	EOF
     +
     +	cat >expect <<-EOF &&
     +	size
     +	type
    -+	$(git rev-parse two:two.t) $(test_file_size two.t) blob
    -+	$(git rev-parse two:two.t) $(test_file_size two.t) blob
    ++	$two_oid $two_size blob
    ++	$two_oid $two_size blob
     +	0000
     +	EOF
     +
4:  8fb55d9b54 < -:  ---------- fetch-object-info: parse type from server response
-:  ---------- > 6:  3929b1a6fc fetch-object-info: parse type from server response
5:  70e65acd83 ! 7:  35e6b6a068 serve: advertise type capability
    @@ t/t1017-cat-file-remote-object-info.sh: test_expect_success 'remote-object-info
      		cd "$daemon_parent/daemon_client_empty" &&
      
     -		echo "" >expect &&
    -+		echo $hello_type >expect &&
    ++		echo "$hello_type" >expect &&
      		git cat-file --batch-command="%(objecttype)" >actual <<-EOF &&
      		remote-object-info "$GIT_DAEMON_URL/parent" $hello_oid
      		EOF
6:  4fe367eb58 ! 8:  fe8163ebab cat-file: unify default format
    @@ Documentation/gitprotocol-v2.adoc: object-info
      Its main purpose is to allow a client to make decisions based on this
     -information without having to fully fetch objects. Object size is the only
     -information that is currently supported.
    -+information without having to fully fetch objects. Object size and type are the
    -+only information currently supported.
    ++information without having to fully fetch objects. Currently only object size
    ++and type are supported.
      
      An `object-info` request takes the following arguments:
      
    @@ Documentation/gitprotocol-v2.adoc: space.
     +	obj-val = obj-size | obj-type
     +
     +	obj-info = obj-id [SP [obj-val *(SP obj-val)]]
    ++
    ++The values in `obj-info` appear in the same order as the corresponding `attr`
    ++lines, with exactly one value per requested attribute.
      
      If the server does not recognize the OID, the response will be `<oid> SP`
      regardless of the number of attributes requested.
     
      ## builtin/cat-file.c ##
     @@ builtin/cat-file.c: static void parse_cmd_remote_object_info(struct batch_options *opt,
    - 	struct object_info *remote_object_info = NULL;
    + 	char *line_to_split;
    + 	struct fetch_object_info_results results = FETCH_OBJECT_INFO_RESULTS_INIT;
      	struct oid_array object_info_oids = OID_ARRAY_INIT;
    - 	struct string_list object_info_options = STRING_LIST_INIT_NODUP;
     -	const char *saved_format = opt->format;
      
      	if (strlen(line) >= MAX_REMOTE_OBJ_INFO_LINE)
    @@ builtin/cat-file.c: static void parse_cmd_remote_object_info(struct batch_option
      	data->skip_object_info = 0;
     -	opt->format = saved_format;
      
    - 	for (size_t i = 0; i < object_info_oids.nr; i++)
    - 		free_object_info_contents(&remote_object_info[i]);
    + 	free_fetch_object_info_results(&results);
    + 	free(line_to_split);
     
      ## t/t1017-cat-file-remote-object-info.sh ##
     @@ t/t1017-cat-file-remote-object-info.sh: test_expect_success 'batch-command remote-object-info git:// default filter' '

---
base-commit: 71e19e8d2713f385c3fcef59cf6f29bcbd93d91f
change-id: 20260724-objecttype-support-ea1ef6941d07


  parent reply	other threads:[~2026-08-03 14:40 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-25 11:55 [PATCH GSoC 0/5] cat-file: extend remote-object-info to support %(objecttype) Pablo Sabater
2026-07-25 11:55 ` [PATCH GSoC 1/5] protocol-caps: add type support to object-info Pablo Sabater
2026-07-29  9:53   ` Chandra Pratap
2026-07-29 11:18     ` Pablo Sabater
2026-07-29 15:40     ` Junio C Hamano
2026-07-29 22:39   ` Karthik Nayak
2026-07-25 11:55 ` [PATCH GSoC 2/5] fetch-object-info: parse type from server response Pablo Sabater
2026-07-29  9:57   ` Chandra Pratap
2026-07-29 12:05     ` Pablo Sabater
2026-07-29 17:06       ` Chandra Pratap
2026-07-29 22:47   ` Karthik Nayak
2026-07-29 22:53     ` Karthik Nayak
2026-07-25 11:55 ` [PATCH GSoC 3/5] fetch-object-info: request all supported options dynamically Pablo Sabater
2026-07-29  9:57   ` Chandra Pratap
2026-07-29 12:07     ` Pablo Sabater
2026-07-25 11:55 ` [PATCH GSoC 4/5] serve: advertise type capability Pablo Sabater
2026-07-29  9:58   ` Chandra Pratap
2026-07-29 12:15     ` Pablo Sabater
2026-07-25 11:55 ` [PATCH GSoC 5/5] cat-file: unify default format Pablo Sabater
2026-07-29  9:59   ` Chandra Pratap
2026-07-29 12:23     ` Pablo Sabater
2026-07-29  9:52 ` [PATCH GSoC 0/5] cat-file: extend remote-object-info to support %(objecttype) Chandra Pratap
2026-07-29 12:34   ` Pablo Sabater
2026-07-31 19:49 ` [PATCH GSoC v2 0/6] " Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 1/6] fetch-object-info: request all supported options dynamically Pablo Sabater
2026-07-31 23:16     ` Junio C Hamano
2026-07-31 19:49   ` [PATCH GSoC v2 2/6] t5701: use the test_file_size() helper Pablo Sabater
2026-08-01  4:27     ` Junio C Hamano
2026-08-01 20:49       ` Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 3/6] protocol-caps: add type support to object-info Pablo Sabater
2026-08-01  4:55     ` Junio C Hamano
2026-07-31 19:49   ` [PATCH GSoC v2 4/6] fetch-object-info: parse type from server response Pablo Sabater
2026-08-01  5:04     ` Junio C Hamano
2026-08-01 13:38       ` Junio C Hamano
2026-08-01 22:20         ` Pablo Sabater
2026-08-01 23:14           ` Jeff King
2026-08-01 23:29             ` Jeff King
2026-08-02  2:02               ` Junio C Hamano
2026-08-02 12:33                 ` Pablo Sabater
2026-08-02 15:43                   ` Jeff King
2026-08-02 16:35                     ` Junio C Hamano
2026-08-02 16:24                   ` Junio C Hamano
2026-08-02 16:38                     ` Jeff King
2026-08-02 22:24                       ` Junio C Hamano
2026-08-01 21:28       ` Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 5/6] serve: advertise type capability Pablo Sabater
2026-08-01 12:12     ` Chandra Pratap
2026-08-01 21:30       ` Pablo Sabater
2026-07-31 19:49   ` [PATCH GSoC v2 6/6] cat-file: unify default format Pablo Sabater
2026-08-03 14:39 ` Pablo Sabater [this message]
2026-08-03 14:39   ` [PATCH GSoC v3 1/8] t5701: use test_file_size() to get the size of a file Pablo Sabater
2026-08-03 17:21     ` Junio C Hamano
2026-08-03 21:12       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 2/8] fetch-object-info: detect truncated server responses Pablo Sabater
2026-08-03 18:18     ` Junio C Hamano
2026-08-03 21:30       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 3/8] fetch-object-info: pass arguments directly instead of a struct Pablo Sabater
2026-08-03 18:23     ` Junio C Hamano
2026-08-03 14:39   ` [PATCH GSoC v3 4/8] fetch-object-info: use dedicated struct for the results Pablo Sabater
2026-08-03 18:28     ` Junio C Hamano
2026-08-03 21:46       ` Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 5/8] protocol-caps: add type support to object-info Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 6/8] fetch-object-info: parse type from server response Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 7/8] serve: advertise type capability Pablo Sabater
2026-08-03 14:39   ` [PATCH GSoC v3 8/8] cat-file: unify default format Pablo Sabater

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260803-objecttype-support-v3-0-7176fecf7950@gmail.com \
    --to=pabloosabaterr@gmail.com \
    --cc=chandrapratap3519@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=karthik.188@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox