On Mon, May 1, 2017 at 6:35 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Brandon Williams <bmwill@xxxxxxxxxx> writes:
>
>> 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
>
> The reason is because the superproject already records where the
> HEAD in the submodule should be, when any of its commits is checked
> out. The tip of a branch (which one???)
The one as configured (submodule.NAME.branch
> in a submodule may match
> that commit, in which case there is nothing gained by having you on
> that branch,
Being on a branch has some advantages, e.g. easier pushing, not
worrying about losing commits due to gc, an easier "name" in a literal sense.
> or it may not match that commit, in which case it is
> unclear what should happen.
Yes, I anticipate this to be the main point of discussion.
> Leaving your submodule on the branch
> would mean the state of your tree as a whole does not match what the
> checkout operation in the superproject wanted to create. Resetting
> the branch would mean you may lose the history of the branch.
or telling the user via die(), that there is a mismatch.
(you may want to run git submodule update --remote to fix the situation)
> Thinking of the detached HEAD state as an implicit unnamed branch
> that matches the state the superproject checkout expects was
> conceptually one of the cleanest choices.
Assuming this is the cleanest design, we may want to change the
message of git-status, then.
Unlike the scary detached HEAD message (incl long hint), we may just
want to say
$ git status
In submodule 'foo'
You're detached exactly as the superprojects wants you to be.
Nothing to worry.
> But all of the above concentrates on what should happen immediately
> after you do a checkout in the superproject, and it would be OK for
> a sight-seer. Once you want to work in the submodules to build on
> their histories, not being on a branch does become awkward. For one
> thing, after you are done with the work in your submodule, you would
> want to update the superproject and make a commit that records the
> commit in the submodule, and then you would want to publish both the
> superproject and the submodule because both of them are now
> updated. The commit in the superproject may be on the branch that
> is currently checked out, but we don't know what branch the commit
> in the submoudule should go.
>
> The submodule.<name>.branch configuration may be a good source to
> learn that piece of information,
Glad we agree up to this point.
> but it does not fully solve the
> issue. It is OK for the tip of that branch to be at or behind the
> commit the superproject records, but it is unclear what should
> happen if the local tip of that branch is ahead of the commit in the
> superproject when checkout happens.
right. It is still unclear to me as well. I'll have to think about the
various modes of operation.
> By the way, how does this topic work with the various checkout modes
> that can be specified with submodule.<name>.update?
This series currently does not touch git-submodule, but in principle
we could just run "submodule--helper reattach-HEAD" after any operation
and then see if we can attach a HEAD (likely for "update=checkout",
but in "merge" we may want to fast-forward the branch, and in "rebase"
we might want to reset (noff) to the tip.
I'll think about this more.
Thanks,
Stefan