Re: [PATCH 3/3] rev-list: add --allow-missing-tips to be used with --missing=...

[Christian Couder <christian.couder@gmail.com>]

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.

> If there is no plausible use case, perhaps we can treat
> it as a mere bugfix to the existing --missing mechanism, especially
> given that support of commits in "--missing" itself is relatively
> a new thing.

`--missing=...` detecting missing commits is new, but it might have
been used to find missing blobs or trees for some time as it exists
since:

caf3827e2f (rev-list: add list-objects filtering support, 2017-11-21)

> If we can do this as a bugfix that is always on when --missing is
> used, then we do not have to worry about adding another tasteless
> loop outside the main command line parser, which is a huge upside
> ;-).

Even if I very much dislike the tasteless loops, I'd rather not risk
user regressions by changing how `git rev-list --missing=...` handles
errors in the commits it is passed as arguments. See my other message
responding to your previous comments about how I'd prefer we handle
this.