On Thu, Feb 1, 2024 at 10:27 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Christian Couder <christian.couder@xxxxxxxxx> 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.
