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 prefer submodule.<name>.local-branch for the submodule's local
branch name. I also prefer 'checkout' to 'head', because 'checkout'
already exists in non-submodule Git for switching between local
branches.
> # 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.
> # 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). 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].
> 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.
> What do you think? Better?
I don't think so. To elaborate the idea I sketched out here [2], say
you want:
Superproject branch Submodule branch Upstream branch
=================== ================ ===============
master master master
super-feature master master
my-feature my-feature master
other-feature other-feature other-feature
That's only going to work with per-superproject-branch configs for
both the local and remote branches. Using the same name for both
local and remote branches does not work.
Let me motivate each of the combinations in the above table:
* master, master, master: The stable trunk.
* super-feature, master, master: A superproject feature that works
with the stock submodule.
* my-feature, my-feature, master: A superproject feature that needs an
improved submodule, but wants to integrate upstream master changes
during development.
* other-feature, other-feature, other-feature: A superproject feature
that needs an improved submodule, and wants to integrate
other-feature changes that are also being developed upstream.
The deal-breaker for recycling submodule.<name>.branch to also mean
the local branch name is the {my-feature, my-feature, master} case.
Do we want to force submodule developers to always match the upstream
name of the feature branch they'd like to integrate with? What if
there is no upstream my-feature branch (and the superproject developer
pushes submodule branches upstream via email)? Making the local
branch name independently configurable avoids these issues with a
minimal increase in complexity.
Cheers,
Trevor
[1]: http://article.gmane.org/gmane.comp.version-control.git/240177
[2]: http://article.gmane.org/gmane.comp.version-control.git/240180
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
