>From Philippe Blain, Sun 01 Mar 2020 at 23:45:02 (-0500) : > > From previous testing I had done, when the submodule is modified (either modified content, > new commits or new commits, staged) and `git reset` is invoked (and so `git reset HEAD` is assumed), > the submodule is only touched if `--hard` or `--merge` is given, > i.e. not when `--soft`, `--mixed` (the default action) or `--keep` are given. > So this is in line with this option just coming into play "When the working tree is updated", as you wrote. Yes essentially reset.c only update the value of submodule.recurse according to --recurse-submodules. Then it is 'unpack-trees.c' that handle recursive submodules. > However I just noticed that according to the doc `--merge` should abort in that case (I think?), but it does not if > `--recurse-submodules` is given. I don’t know if it’s a doc oversight or a real bug though... Good question... > > + work trees of submodules will not be updated. Just like > > + linkgit:git-submodule[1], this will detach `HEAD` of the submodule. > In fact `git submodule` does not unconditionally detach the submodules HEAD > (if `git submodule update` is invoked and a branch is checked out in the submodule that points > to the same commit as the one recorded in the superproject, the HEAD is not detached and the branch > stays checked out unless `--force` is given.) So I would instead link to `checkout`, > which does unconditionally detach the submodules HEAD. Ok. I copied the above line from git-switch[1]. Should I also update it? git-checkout[1] also says that git-submodule will detach HEAD by the way.
