Christian Couder <christian.couder@xxxxxxxxx> writes: >> 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. Yes, and they are missing errors for starting point objects right now, which is a bug, just like they were missing output for commit objects before we fixed it recently? >> 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) So it fixes a long-standing bug. So what? Especially given that the change in behaviour is to error out only when the user gave an object name for a missing object, and we know the user wants to be notified on all missing objects "found" during the traversal, it smells like (1) a rare enough case that may not matter in the real world and (2) the existing scripts that may feed potentially missing objects to the command would be doing an extra check to ensure what they feed the command are not missing, in order to avoid triggering that "starting point objects induce an error instead of --missing=print report" bug, and the bugfix will make such a workaround unnecessary.
