2014/1/6 Heiko Voigt <hvoigt@xxxxxxxxxx>:
>
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html