Re: [PATCH 0/5] Some submodule bugfixes and "reattaching detached HEADs"

From: Brandon Williams <bmwill@google.com>
Date: May 1, 2017, 18:24 UTC
Message-ID: <20170501182405.GG39135@google.com>
In-Reply-To: <20170501180058.8063-1-sbeller@google.com>

On 05/01, Stefan Beller wrote:

Show 16 quoted lines

> 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.

I don't know why submodules were originally designed to be in a detached HEAD state but I much prefer working on branches (as I'm sure many other developers do) so the prospect of this becoming the norm is exciting! :D

> 
> 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")

Yes, I agree. If we have a particular name of a branch configured to be tracked, then we should respect that and try to attach HEAD onto that branch name.

> * 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.

I think it would be fine to create the branch, just as long as it doesn't already exist as I can't think of a negative impact of this (aside from maybe having more branches in the submodules after a prolonged time period?)

> * 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.

The later seems like the most correct thing to do. It would be unfortunate if I had done some work on top of the master branch in a submodule (which wasn't reflected in the superproject), then done a 'checkout master' in the super project only to go back to the submodule and find that all my work is gone! (Well not gone, but you'd have to go into the scary reflog!) It just makes sense to leave HEAD in a detached state here as it prevents loss of work.

Show 20 quoted lines

> 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
>

-- 
Brandon Williams