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

2014/1/6 Heiko Voigt [off-list ref]:

I agree. If we were to support this more easily we could add a
configuration option so you can omit the --remote (i.e.:
submodule.<name>.remote=true, as I also suggested in the other email).

That way the developer checking out a branch in flight does not even
need to know whether (and which) submodules sha1s are still in flight
and temporarily set this configuration in the branches .gitmodules file.

"submodule.<name>.remote" can be useful but can be added later to aid
the current use case.

To not break the existing behavior what it's really needed here, IMO,
is a "submodule.<name>.attached" property that says two things:
- at the first clone on "git submodule update" stay attached to
"submodule.<name>.branch";
- implies "--remote", as it's the only thing that makes sense when the
submodules are attached.

My patch at the current unreleased state does exactly this.

Maybe that could actually be the attach operation Francesco is
suggesting:

        git submodule attach [--pull] <submodule path> <branchname>

will attach the specified submodule to a branch. That means it changes
the .gitmodule file accordingly and stages it. With the --pull switch
one can specify whether a local branch tracking the remote branch should
be automatically created. Names and the command format are just a
suggestion here.

That way we can support the

        fork superproject needing submodule changes and send submodule
        changes upstream first.

My patch didn't do this, as the maintainer can do these things quite
easily[1] (maintainer is "cooler" with respect to other devs :) ), but
I think it could be good to also have this feature.

The feature I think that are still needed and you don't mention are:
- an "--attached" switch for the "add" command when the maintainer
create the submodule the first time (DONE in patch);
- a easy way to attach|detach the submodule locally by developer. This should:
    * fix the head state (DONE in patch);
    * fix the local .git/config "submodule.<name>.attached" property
accordingly (DONE in patch, unreleased).

I do the latest in the "update" command but it seems bad to touch
.git/config in the "update" command...

Maybe we should have a "git submodule head" command that does all
these things: --attach (for the maintainer), --attach|--detach (for
the developer).

[1]
$ ( cd submodule && git branch newbranch && git push -u origin HEAD)
$ git config -f .gitmodules submodule.newbranch.branch newbranch
$ git config -f .gitmodules submodule.newbranch.attached true
$ git add . && git commit -m "Forked superproject" && git push