Re: Re: [RFC v2] submodule: Respect requested branch on all clones

[Francesco Pretto <ceztko@gmail.com>]

2014/1/8 W. Trevor King <wking@tremily.us>:
> Note that I've moved away from “submodule.<name>.branch
> set means attached” towards “we should set per-superproject-branch
> submodule.<name>.local-branch explicitly” [1].
>

Honestly, I'm having an hard time to follow this thread. Also, you
didn't update the patch. If you were endorsed by someone (Junio,
Heiko, ...) for the "submodule.<name>.local-branch" feature please
show me where.

I somehow understand the point of the
"submodule.<name>.local-branch" property, but I can't "see" the the
workflow. Please, show me some hypothetical scripting example with as
much complete as possible workflow (creation, developer update,
mantainers creates feature branch, developer update, developer attach
to another branch). Also, consider I proposed to support the attached
HEAD path to reduce complexity and support a simpler use case for
git submodules. I would be disappointed if the complexity is reduced in a
way and augmented in another.

> On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
>> # Attach the submodule HEAD to <branch>.
>> # Also set ".git/config" 'submodule.<module>.branch' to <branch>
>> $ git submodule head -b <branch> --attach <module>
> [...]
> I also prefer 'checkout' to 'head', because 'checkout'
> already exists in non-submodule Git for switching between local
> branches.
>

I can agree with similarity to other git commands, but 'checkout' does
not give me the idea of something that writes to ".git/config" or
".gitmodules".

>> # Attach the submodule HEAD to 'submodule.<module>.branch'.
>> # If it does not exists defaults to <remote>/master
>> $ git submodule head --attach <module>
>
> Defaulting to the configured local branch is fine, but I think it
> should default to 'master' if no local branch is configured.  This
> should not have anything to do with remote-tracking branches (that's
> what 'submodule update' already handles).  I don't understand why
> remote-tracking-branch integration keeps getting mixed up with
> local-branch checkout.
>

Yep, it should default to "master", my fault.

>> # Unset  ".git/config" 'submodule.<module>.branch'
>> # Also attach or detach the HEAD according to what is in ".gitmodules":
>> # with Trevor's patch 'submodule.<module>.branch' set means attached,
>> # unset means detached
>> $ git submodule head --reset <module>
>
> To me this reads “always detach HEAD” (because it unsets
> submodule.<name>.branch, and submodule.<name>.branch unset means
> detached).

I disagree: this would remove only the value in ".git/config". If the
value is till present in ".gitmodules", as I wrote above, the behavior
of what is in the index should be respected as for the other
properties. Also it gives a nice meaning to a switch like --reset :
return to how it was before.

>> NOTE: feature branch part!
>>
>> # Set ".gitmodules" 'submodule.<module>.branch' to <branch>
>> $ git submodule head -b <branch> --attach --index <module>
>>
>> # Unset ".gitmodules" 'submodule.<module>.branch'
>> $ git submodule head --reset --index <module>
>> ---------------------------------------------------------------------
>
> These are just manipulating .gitmodules.  I think we also need
> per-superproject-branch configs under the superproject's .git/ for
> developer overrides.
>

I disagree: in my idea the --index switch is a maintainer only command
to modify the behavior of the developers and touch only indexed files
(.gitmodules, or create a new submodule branch). It expressly don't
touch .git/config.