A couple days before the 2.19 release we had a bug report about broken submodules[1] and reverted[2] the commits leading up to them.

The behavior of said bug fixed itself by taking a different approach[3], specifically by a weaker enforcement of having core.worktree set in a submodule [4].

The revert [2] was overly broad as we neared the release, such that we wanted to rather keep the known buggy behavior of always having core.worktree set, rather than figuring out how to fix the new bug of having 'git submodule update' not working in old style repository setups.

This series re-introduces those reverted patches, with no changes in code, but with drastically changed commit messages, as those focus on why it is safe to re-introduce them instead of explaining the desire for the change.

[1] https://public-inbox.org/git/2659750.rG6xLiZASK@twilight
[2] f178c13fda (Revert "Merge branch 'sb/submodule-core-worktree'", 2018-09-07)
[3] 4d6d6ef1fc (Merge branch 'sb/submodule-update-in-c', 2018-09-17)
[4] 74d4731da1 (submodule--helper: replace connect-gitdir-workingtree by ensure-core-worktree, 2018-08-13)

Stefan Beller (4):
submodule update: add regression test with old style setups
submodule: unset core.worktree if no working tree is present
submodule--helper: fix BUG message in ensure_core_worktree submodule deinit: unset core.worktree

 builtin/submodule--helper.c        |  4 +++-
 submodule.c                        | 14 ++++++++++++++
 submodule.h                        |  2 ++
 t/lib-submodule-update.sh          |  5 +++--
 t/t7400-submodule-basic.sh         |  5 +++++
 t/t7412-submodule-absorbgitdirs.sh |  7 ++++++-
 6 files changed, 33 insertions(+), 4 deletions(-)

2.20.0.rc2.403.gdbc3b29805-goog