Re: [PATCH 4/5] rebase -i: don't fork git checkout

Hi Elijah,

Le 2021-09-09 à 11:01, Elijah Newren a écrit :

Hi,

On Thu, Sep 9, 2021 at 6:57 AM Phillip Wood [off-list ref] wrote:

quoted

<snip>

quoted

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.