From: Derrick Stolee <stolee@gmail.com>
To: Siddharth Asthana <siddharthasthana31@gmail.com>, git@vger.kernel.org
Cc: chriscool@tuxfamily.org, toon@iotcl.com, ps@pks.im,
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 07:44:44 -0400 [thread overview]
Message-ID: <8a3e3a38-3f8e-4363-9e45-b5610c3efbc5@gmail.com> (raw)
In-Reply-To: <9e2ca91d-9091-4d4d-9427-ec8a23ee8909@gmail.com>
On 4/20/2026 6:24 AM, Siddharth Asthana wrote:
> On 20/04/26 04:06, Derrick Stolee wrote:
>> On 4/19/26 4:48 AM, Siddharth Asthana wrote:
>>> - if (line_term)
>>> + if (arg_missing_action == MA_PRINT_ONLY) {
>>> + printf("%s", oid_to_hex(&entry->entry.oid));
>>> + putchar(line_term);
>>
>> Is there a reason you didn't use a printf("%s%c") here to
>> put the oid and line_term together?
>
>
> I just followed the existing pattern in the same function where every other path uses a separate putchar(line_term). Happy to combine if you prefer.
>>> + } else {
>>> printf("%s%cmissing=yes", oid_to_hex(&entry->entry.oid),
>>> info_term);
I was just looking at this line in the patch context as
comparison, but if there are other patterns that prefer
"printf(); putc();" then that's enough for me.
>>> - if (show_disk_usage)
>>> + if (show_disk_usage && arg_missing_action != MA_PRINT_ONLY)
>>> print_disk_usage(total_disk_usage);
>>
>> I'm a little worried about all of these checks that need
>> special-casing. These seem like options that are enabled
>
> Phillip suggested making this a separate --missing-only flag that composes with existing --missing= modes - I think that's a better design. will work v2 around it.
That's a good idea. '--missing=' formats the output while
your mode _filters_ the output. They are different things
and worth different options.
>> how this interacts with those options. And perhaps some
>> warnings to say "these options are not compatible".
>>
>> On that note: this patch is missing a document update.
>
>
> There is a doc update in rev-list-options.doc, but it doesn't cover interactions with --count/--disk-usage. Will fix in v2.
You're right. I thought I had looked for it in the patch
but missed it somehow.
Thanks,
-Stolee
next prev parent reply other threads:[~2026-04-20 11:44 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 [this message]
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
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=8a3e3a38-3f8e-4363-9e45-b5610c3efbc5@gmail.com \
--to=stolee@gmail.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=justin@parity.io \
--cc=karthik.188@gmail.com \
--cc=ps@pks.im \
--cc=siddharthasthana31@gmail.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox