On Thu, Jan 09, 2014 at 12:07:56AM +0100, Francesco Pretto wrote: > After long thoughts, I think your idea about a local branch with a > differently named remote branch looks interesting but I would be > extremely cautious to add a ' submodule.<name>.local-branch' now. Do > we have a similar mechanism on regular repository clones?
The default upstream branch is currently configured with branch.<name>.merge. Earlier , I suggested we piggyback on this for the submodule's upstream branches, and only use submodule.<name>.branch for the initial setup. That would allow developers to configure upstreams on a per-submodule-branch basis. We should probably fall back to submodule.<name>.branch if the submodule does not have a branch.<name>.merge configured. However, submodule.<name>.local-branch has nothing to do with remote repositories or tracking branches. It just selects the preferred submodule branch for the superproject branch. This will only work for in-tree .gitmodules configs (since the contents are per-branch). I don't have a good idea for where local overrides would live. We'd want something like branch.<superproject-branch>.submodule.<submodule-name>.local-branch: [branch "my-feature"] remote = origin merge = refs/heads/my-feature [submodule "submod"] local-branch = "my-feature" and I don't think Git's config supports such nesting. > We can clone and switch to a branch other than "master" by default, > but can we also have a different remote by default? Sure, the existing submodule.<name>.url defines the remote repository, and the existing submodule.<name>.branch defines the remote branch. The existing code even sets up remote.origin.url and branch.<name>.merge (to the matching refs/heads/<name>) in the the submodule's config. > Also, I think you fear too much that this can't be added also later. We can add submodule.<name>.local-branch support later, but I see no reason not to add it on top of Jens and Jonathan's current submodule checkout work. With increasingly robust submodule checkout support in the core, I expect the amount of update logic stored in git-submodule.sh will decrease significantly. > I think you should pursue your initial proposal of "--branch means > attached" to get it upstream first. It's alone, IMO, a great > improvement on submodules. I can resuscitate that if folks want, but Heiko felt that my initial consolidation didn't go far enough . If it turns out that we're ok with the current level of consolidation, would you be ok with "non-checkout submodule.<name>.update" as the trigger ? I think that adding a halfway step between the current status and full(ish) submodule.<name>.local-branch support is just going to confuse people ;). Cheers, Trevor : http://article.gmane.org/gmane.comp.version-control.git/240164 : http://article.gmane.org/gmane.comp.version-control.git/239968 : http://article.gmane.org/gmane.comp.version-control.git/239973 -- 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
Description: OpenPGP digital signature