On Wed, Apr 8, 2020 at 9:23 AM <ydirson@xxxxxxx> wrote: > > This may be related to another funky behaviour I just noticed, linked > to moving submodules around: > > - when initially created, the $TOP/orig-name submodule's git-dir gets created in > $TOP/.git/modules/orig-name, with $TOP/.git/modules/orig-name/config > containing a core.worktree value pointing to $TOP/orig-name > - when moving the submodule, only the submodule worktree is moved, the git-dir > being the same $TOP/.git/modules/orig-name, where the core.worktree still > points to the old location > > Other unwanted behaviour include "git clean" reporting (and possibly cleaning) > files from the wrong work tree - it took me head-scratching to understand why > "git clean -fdx" was ignoring all the cruft I had in this worktree... > > Why is it that we need a core.worktree setting at all in there ? Removing it > allows "git clean" to do what's expected of it. OTOH it does not make the > original problem go away... Not knowing much about submodules, I'm going to leave submodule issues that don't touch on the merge-machinery or rebase code to someone else to handle. (I'd probably do the same with the merge-machinery and rebase side if I wasn't worried about 2.26.0 regressions in rebase and if I hadn't find a clever way to re-use checkout code to avoid lots of submodule issues while also deleting code in the "ort" merge strategy). Hopefully someone else on the list who knows more about submodules can chime in on the worktree related bits.
