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

2014/1/8 W. Trevor King [off-list ref]:

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:

quoted

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

quoted

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

quoted

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

quoted

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.