Hi Git community, I've been wanting to use the git submodules feature for many years, but have always been put off by the ease with which you could lose work in the past. Much progress has now been made, and with the '[submodule] recurse = true' setting and the 'update = merge' setting, it's starting to look much safer. The only remaining sharp edge seems to be the 'git pull' command. It doesn't seem to respect the 'update = merge' setting, and will overwrite a submodule version in your working copy with the submodule version from your remote, instead of merging or rebasing. I'm not sure if this is by design, or it's a bug? But it seems like a bug, since 'git pull' is respectful of uncommitted changes in the submodule, and also won't overwrite the submodule version if it has been staged in the containing project. Git version: 2.31.1.windows.1 Steps to reproduce: 1. Add a submodule to your project, with the 'update = merge' setting, and default recursion to on: [submodule "modules/mylibrary"] active = true url = <. . .> update = merge [submodule] recurse = true 2. Cd into the submodule, checkout master, and add a new commit 3. Cd back into the enclosing project 4. 'git submodule update --init --recursive --remote' will correctly leave your submodule pointing at the new commit 5. 'git pull --rebase' will correctly leave your submodule pointing at the new commit 6. But 'git pull' will replace your submodule with a detached head, ignoring the 'update = merge' setting This will then lead to lost work when you fail to notice, and commit the reverted submodule version in the enclosing project. Am I wrong to want 'git pull' to use the 'update = merge' setting - is this a feature? Regards, James Limbouris
