From: Linus Arver <linusa@google.com>
To: Christian Couder <christian.couder@gmail.com>,
Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Patrick Steinhardt <ps@pks.im>,
John Cai <johncai86@gmail.com>,
Christian Couder <chriscool@tuxfamily.org>,
Elijah Newren <newren@gmail.com>,
Jeff Hostetler <git@jeffhostetler.com>
Subject: Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...
Date: Wed, 07 Feb 2024 01:57:28 -0800 [thread overview]
Message-ID: <owlyttmkmwaf.fsf@fine.c.googlers.com> (raw)
In-Reply-To: <CAP8UFD3Hfgud19y_K1bZOudkBE-ss1_SgWTRVkJ7gUbYJ400yQ@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> On Thu, Feb 1, 2024 at 10:27 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>> > When such a command is used to find the dependencies of some objects,
>> > for example the dependencies of quarantined objects, it would be
>> > better if the command would instead consider such missing objects,
>> > especially commits, in the same way as other missing objects.
>> >
>> > If, for example `--missing=print` is used, it would be nice for some
>> > use cases if the missing tips passed as arguments were reported in
>> > the same way as other missing objects instead of the command just
>> > failing.
>> >
>> > Let's introduce a new `--allow-missing-tips` option to make it work
>> > like this.
>>
>> An obvious question is if this even needs to be a new option. What
>> are expected use cases where --missing=print without this option is
>> beneficial?
>
> I am not sure if such a case is really beneficial but some
> people/script/forges might rely on an error from `git rev-list
> --missing=print` to propagate back an error to some user interface.
I currently learn toward just making the new flag's behavior be absorved
into the existing "--missing=..." flag. Nevertheless, you raise an
interesting concern.
Perhaps a compromise would be to make "--missing=..." learn the new
behavior of this patch as Junio suggested, but to introduce a new flag,
something like "--fail-on-missing-tips" to fail early if any of the tip
commits' objects are missing? That way we could keep the current
"strict" behavior of complaining if we feed rev-list any tips whose
objects are missing. And for the vast majority of cases the
"--missing=..." flag could (intuitively) gracefully handle tips with
missing objects and you wouldn't have to pass in the additional flag.
IOW, make the minority (certainly not majority, I think?) of users who
really need the error propagation use the (new) extra flag, while the
rest of us (including the version of you who was surprised by the
limited behavior of "--missing=...", enough to write this series) don't
have to.
Thanks.
next prev parent reply other threads:[~2024-02-07 9:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-01 11:58 [PATCH 0/3] rev-list: allow missing tips with --missing Christian Couder
2024-02-01 11:58 ` [PATCH 1/3] revision: clarify a 'return NULL' in get_reference() Christian Couder
2024-02-01 14:53 ` Eric Sunshine
2024-02-01 16:49 ` Christian Couder
2024-02-01 11:58 ` [PATCH 2/3] t6022: fix 'even though' typo in comment Christian Couder
2024-02-01 11:58 ` [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing= Christian Couder
2024-02-01 20:20 ` Junio C Hamano
2024-02-02 11:29 ` Christian Couder
2024-02-02 16:47 ` Junio C Hamano
2024-02-01 21:27 ` Junio C Hamano
2024-02-02 11:29 ` Christian Couder
2024-02-02 16:54 ` Junio C Hamano
2024-02-07 9:57 ` Linus Arver [this message]
2024-02-07 16:34 ` Junio C Hamano
2024-02-07 16:38 ` Christian Couder
2024-02-07 9:40 ` Linus Arver
2024-02-07 16:11 ` Christian Couder
2024-02-07 20:48 ` Linus Arver
2024-02-08 15:03 ` Christian Couder
2024-02-08 20:42 ` Linus Arver
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=owlyttmkmwaf.fsf@fine.c.googlers.com \
--to=linusa@google.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@jeffhostetler.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johncai86@gmail.com \
--cc=newren@gmail.com \
--cc=ps@pks.im \
/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;
as well as URLs for NNTP newsgroup(s).