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

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


[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

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to