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

On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:

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.

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.

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

These are just manipulating .gitmodules. I think we also need per-superproject-branch configs under the superproject's .git/ for developer overrides.

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