From: Siddharth Asthana <siddharthasthana31@gmail.com>
To: phillip.wood@dunelm.org.uk, Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, chriscool@tuxfamily.org, toon@iotcl.com,
karthik.188@gmail.com, justin@parity.io
Subject: Re: [PATCH v1 1/1] rev-list: add --missing=print-only mode
Date: Mon, 20 Apr 2026 16:07:27 +0530 [thread overview]
Message-ID: <3363a365-9529-44e5-bc4e-ba19bf97ed97@gmail.com> (raw)
In-Reply-To: <491a27af-3ea4-4978-9d51-9c540ad31589@gmail.com>
On 20/04/26 14:27, Phillip Wood wrote:
> On 20/04/2026 08:43, Patrick Steinhardt wrote:
>> On Sun, Apr 19, 2026 at 02:18:40PM +0530, Siddharth Asthana wrote:
>>
>>> static struct oidmap missing_objects;
>>> enum missing_action {
>>> - MA_ERROR = 0, /* fail if any missing objects are encountered */
>>> - MA_ALLOW_ANY, /* silently allow ALL missing objects */
>>> - MA_PRINT, /* print ALL missing objects in special section */
>>> - MA_PRINT_INFO, /* same as MA_PRINT but also prints missing
>>> object info */
>>> + MA_ERROR = 0, /* fail if any missing objects are encountered */
>>> + MA_ALLOW_ANY, /* silently allow ALL missing objects */
>>> + MA_PRINT, /* print ALL missing objects in special section */
>>> + MA_PRINT_INFO, /* same as MA_PRINT but also prints missing
>>> object info */
>>> + MA_PRINT_ONLY, /* print ONLY missing objects, without the "?"
>>> prefix */
>>
>> Makes me wonder whether we'll eventually also want to have
>> `MA_PRINT_INFO_ONLY`.
>
> Perhaps we'd be better to add a "--missing-only" option that limits the
> output to missing objects? That would avoid the problem of "--
Make sense, its orthogonal to --missing= and handles print-info-only for
free.
Question though: should --missing-only without --missing=print (or
print-info) be an errro? I am leaning towards requiring it explicitly so
the behavior is always obvious.
Will rework v2 around this.
> missing=print-only" not really explaining what it does as well.
>
>>> +for obj in "HEAD~1" "HEAD~1^{tree}" "HEAD:1.t"
>>> +do
>>> + test_expect_success "rev-list --missing=print-only with missing
>>> $obj" '
>>> + oid="$(git rev-parse $obj)" &&
>>> + path=".git/objects/$(test_oid_to_path $oid)" &&
>>> +
>>> + # Capture present OIDs before hiding anything.
>>> + git rev-list --objects --no-object-names HEAD ^$obj
>>> >present.raw &&
>>> +
>>> + mv "$path" "$path.hidden" &&
>>> + test_when_finished "mv $path.hidden $path" &&
>>> +
>>> + git rev-list --missing=print-only --objects --no-object-names \
>>> + HEAD >actual &&
>>> +
>>> + # Only the missing OID should appear, without the "?" prefix.
>>> + grep "^$oid$" actual &&
>>> +
>>> + # Present objects must NOT appear in the output.
>>> + while read present_oid
>>> + do
>>> + ! grep "^$present_oid$" actual || return 1
>>> + done <present.raw
>>
>> How many present object IDs do we have? I'm a bit worried that we now
>> execute grep(1) hundreds of times. Can we maybe do some tricks with
>> comm(1) instead?
>
> If we want to verify that it only prints a single oid then
>
> echo $oid >expect &&
> test_cmp expect actual
>
> would be much simpler more helpful if the test fails
yeah much cleaner, will use it. Thanks
>
> Thanks
>
> Phil
Thanks,
Asthana
next prev parent reply other threads:[~2026-04-20 10:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 8:48 [PATCH v1 0/1] rev-list: add --missing=print-only mode Siddharth Asthana
2026-04-19 8:48 ` [PATCH v1 1/1] " Siddharth Asthana
2026-04-19 22:36 ` Derrick Stolee
2026-04-20 10:24 ` Siddharth Asthana
2026-04-20 11:44 ` Derrick Stolee
2026-04-20 7:43 ` Patrick Steinhardt
2026-04-20 8:57 ` Phillip Wood
2026-04-20 9:55 ` Patrick Steinhardt
2026-04-20 10:37 ` Siddharth Asthana [this message]
2026-04-20 11:00 ` Kristoffer Haugsbakk
2026-04-20 10:33 ` Siddharth Asthana
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=3363a365-9529-44e5-bc4e-ba19bf97ed97@gmail.com \
--to=siddharthasthana31@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=justin@parity.io \
--cc=karthik.188@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
--cc=toon@iotcl.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.