On Tue, Apr 18, 2017 at 9:18 PM, Junio C Hamano <gits...@pobox.com> wrote: > Stefan Beller <sbel...@google.com> 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?
We reset the submodule to the commit as recorded in the superproject, detaching its HEAD. > 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. I agree. >
