Re: What's cooking in git.git (Aug 2026, #02)

"Pablo Sabater" <[email protected]> writes:

> On Thu Aug 6, 2026 at 12:48 AM CEST, Junio C Hamano wrote:
>>
>> * ps/cat-file-remote-object-info-type (2026-08-04) 10 commits
>>  - cat-file: unify default format
>>  - serve: advertise type capability
>>  - fetch-object-info: parse type from server response
>>  - protocol-caps: add type support to object-info
>>  - fetch-object-info: die() on the remaining error path
>>  - fetch-object-info: use dedicated struct for the results
>>  - fetch-object-info: pass arguments directly instead of a struct
>>  - fetch-object-info: detect malformed server responses
>>  - t5701: use test_file_size() to get the size of a file
>>  - Merge branch 'ps/cat-file-remote-object-info' into ps/cat-file-remote-object-info-type
>>
>>  The 'remote-object-info' command for 'git cat-file --batch-command'
>>  has been extended to support the '%(objecttype)' placeholder.
>>
>>  Needs review.
>>  cf. <[email protected]>
>>  cf. <[email protected]>
>>  source: <[email protected]>
>>
>
> Hi,
>
> The topic ps/cat-file-remote-object-info graduated to 'master' last
> What's cooking [1], so ps/cat-file-remote-object-info-type can go on top
> of 'master' as is and the merge requirement can be dropped.

Sorry, but what do you mean by a 'merge requirement'?

I generally keep the same base as before when there is no reason to
rebase.  It makes easier to view the differences between iterations.
'git diff @{1} @{0}' would work just fine, for example.  If you
rebase, you would need to guess from the output of the 'range-diff'
command, which, while much better than nothing, is still not easy to
read.

The above is kept on the same synthetic base, as I did not (and do
not) see any need to rebase, but perhaps you have reasons I missed?

By the way, I just noticed that the commit count includes the number
of synthetic bases, which may be a bit confusing, if not wrong.  The
tooling to maintain the 'What's cooking' report may rely on the
count exactly matching the number of lines below the headline, which
is the number of commits in the 'git log --first-parent master..'
chain.  I might look into changing it to show the number of
contributor patches in the series, but it may take some time before
I get to it.