Stefan Beller <sbeller@xxxxxxxxxx> writes: > git-reset is yet another working tree manipulator, which should > be taught about submodules. > > One use case of "git-reset" is to reset to a known good state, > and dropping commits that did not work as expected. > > In that case one of the expected outcomes from a hard reset > would be to have broken submodules reset to a known good > state as well. A test for this was added in a prior patch. When "git reset --hard" at the top-level superproject updates a gitlink in the index to a commit that was different from what was checked out in the working tree of the submodule, what should happen? Do we reset the tip of the current branch in the submodule to point at the commit the index of the top-level records? Do we detach the HEAD in the submodule to point at the commit? Something else that is configurable? Or do we just run "git reset --hard" in each submodule (which may leave submodule's HEAD different from what is recorded in the index of the superproject)? "... to a known good state as well" does not help answering the above.