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

From: Francesco Pretto <ceztko@gmail.com>
Date: Jan 6, 2014, 23:10 UTC
Message-ID: <CALas-ijXQFcUHWk-jJrLifqsMHAKo6NNKya+jR6RJGGDXY76hg@mail.gmail.com>
In-Reply-To: <20140106160202.GE27265@t2784.greatnet.de>

2014/1/6 Heiko Voigt <hvoigt@hvoigt.net>:

Show 9 quoted lines

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

Show 16 quoted lines

> 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