Jeff King <peff@xxxxxxxx> writes: >> Generally, I decided to move it after option-parsing, so it wouldn't >> be called if we are hitting an option-parse error. > > Playing devil's advocate: would option parsing ever access an object? I > think in most cases the answer is no, but I could imagine it happening > for some special cases (e.g., update-index uses callbacks to act on > options as we parse them, since order is important). > > So I think as a general principle it makes sense for commands to set > this flag as early as possible. 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.
