Hi Elijah, Le 2021-09-09 à 11:01, Elijah Newren a écrit :
Hi, On Thu, Sep 9, 2021 at 6:57 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
<snip>
merge-recursive.c:update_file_flags() does this when updating the work tree if (S_ISGITLINK(contents->mode)) { /* * We may later decide to recursively descend into * the submodule directory and update its index * and/or work tree, but we do not do that now. */ update_wd = 0; goto update_index; } so it looks like it does not update the submodule directory. Given merge-ort is now the default perhaps it's time for rebase (and cherry-pick/revert) to start reading the submodule config settings (we parse the config before we know if we'll be using merge-ort so I don't know how easy it would be to only parse the submodule settings if we are using merge-ort).I'd just parse any needed config in all cases. The submodule settings aren't going to hurt merge-recursive; it'll just ignore them. (Or are you worried about a mix-and-match of rebase calling both checkout and merge code doing weird things, and you'd rather not have the checkout bits update submodules if the merges won't?)
Thanks for your input. I agree that reading the config in all cases would be simpler. We could even decide that since ort is the new default, the submodule support will not be "backported" to merge recursive (that would be way simpler to implement, I think) This way we can just document it as such and be done with it. But anyway, I think this is kind of orthogonal to this here series and should be done separately. Cheers, Philippe.
