Stefan Beller <sbel...@google.com> writes:
> In e1111cef23 (inline lookup_replace_object() calls, 2011-05-15) a
> shortcut for checking the object replacement was added by setting
> check_replace_refs to 0 once the replacements were evaluated to
> not exist. This works fine in with the assumption of only one
> repository in existence.
"works fine in with the..."? I guess s/ in with/ with/?
> The assumption won't hold true any more when we work on multiple
> instances of a repository structs (e.g. one struct per submodule),
> as the first repository to be inspected may have no replacements
> and would set the global variable. Other repositories would then
> completely omit their evaluation of replacements.
>
> This reverts back the meaning of the flag `check_replace_refs` of
> "Do we need to check with the lookup table?" to "Do we need to read
> the replacement definition?", adding the bypassing logic to
> lookup_replace_object after the replacement definition was read.
> As with the original patch, delay the renaming of the global variable
Hmph, if we decided that replace database is per repository
instance, shouldn't this variable also become per repository,
instead of staying to be a system-wide global?
Perhaps that will happpen in a later stage of the series that I
haven't seen yet, I guess. And until that happens, we disable the
optimization and always call into do_lookup_replace_object() when
lookup_replace_object() is called, which is OK.
> static inline const struct object_id *lookup_replace_object(const struct
> object_id *oid)
> {
> - if (!check_replace_refs)
> + if (!check_replace_refs ||
> + (the_repository->objects->replace_map &&
> + the_repository->objects->replace_map->map.tablesize == 0))
Ah, we still have the same optimization, so this looks alright. The
variable's name and semantics do need to be updated--I didn't check
but if this variable is exposed to the end users in any way, such a
fundamental sematic change may be hard to transition, though.
This series looks good so far.
