On Sat, Jun 03, 2023 at 09:28:13AM +0900, Junio C Hamano wrote: > I agree with the "devil's advocate" above; indeed my suggestion to > follow-on work that is enabled by introducing this function, i.e. we > can ensure that the objects already instantiated when the call is > made are not affected by the replace mechanism, was exactly for such > a "we already accessed some objects via the replace mechanism and > then try to close the door of the barn afterwards with this call" > case. > > Indeed, I think "git branch --no-merged 0369cf" resolves the object > name down to a commit object in parse_opt_merge_filter() before > parse_options() call returns. > > Yes. Ah, very good example. Yes, I'd think it would be appropriate to BUG() if disable_replace_refs() is called and anybody has looked up an object already. -Peff
