The first three patches fix bugs in existing submodule code,
sort of independent from the last 2 patches, which are RFCs.
In submodules as of today you always end up with a detached HEAD,
which may be scary to people used to working on branches. (I myself
enjoy working with a detached HEAD).
The detached HEAD in a submodule is the correct in the submodule-as-a-lib
case, but in case you actively want to work inside submodules, you
may want to have proper branch support, e.g. when typing:
git checkout --recuse-submodules master
you may want to have the submodules on the master branch as well.
There are a couple of challenges though:
* We'd probably want to pay attention to the branch configuration
(.gitmodules submodule.NAME.branch to be "." or "foo")
* What if the submodule does not have a master branch?
Jonathan proposed off list that we may just want to create the
branch in the submodule. This is not implemented in this series.
* In case the branch exists in the submodule and doesn't point at the
the object as recorded in the superproject, we may either want to
update the branch to point at the superproject record or we want to
reject the "reattaching HEAD". Patch 4 provides the later.
Any other ideas on why this could be a bad idea or corner cases?
Thanks,
Stefan
Stefan Beller (5):
submodule_move_head: fix leak of struct child_process
submodule_move_head: prepare env for child correctly
submodule: avoid auto-discovery in new working tree manipulator code
submodule--helper: reattach-HEAD
submodule_move_head: reattach submodule HEAD to branch if possible.
builtin/submodule--helper.c | 12 ++++++
submodule.c | 93 ++++++++++++++++++++++++++++++++++++++++-----
submodule.h | 10 +++++
3 files changed, 106 insertions(+), 9 deletions(-)
--
2.13.0.rc1.1.gbc33f0f778