On 6/1/2023 12:36 PM, Victoria Dye wrote: > Derrick Stolee via GitGitGadget wrote: >> From: Derrick Stolee <derrickstolee@xxxxxxxxxx> >> Unfortunately, the existing processes that recurse into submodules do >> not appear to follow object IDs to their contents, so this behavior >> change is not visible in the current implementation. It is something >> valuable for future behavior changes. > > AFAIK, the only '--recurse-submodules' commands that recurse in-process are > 'ls-files' and 'grep'. However, 'grep' does call 'parse_object_or_die()', > which (further down in the call stack) calls 'lookup_replace_object()'. > Maybe I'm misreading and the replaced object isn't actually used, but could > 'git grep --recurse-submodules' be used to test this? You're right. I was laser-focused on 'ls-files', but it shouldn't be hard to construct an example where 'git grep --recurse-submodules' would show different behavior when this config is toggled. >> + /* >> + * Do replace refs need to be checked this run? This variable is >> + * initialized to true unless --no-replace-object is used or >> + * $GIT_NO_REPLACE_OBJECTS is set, but is set to false by some >> + * commands that do not want replace references to be active. >> + */ >> + int read_replace_refs; > > I don't think this comment is accurate anymore, since the repo-scoped > 'read_replace_refs' value is determined *only* by the 'core.usereplacerefs' > config. It's 'replace_refs_enabled()' that makes the overall determination > (taking into account 'GIT_NO_REPLACE_OBJECTS'/'--no-replace-object'). Thank you for catching my mistake here. I'll be sure to update it in v2. Thanks, -Stolee
