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

From: W. Trevor King <wking@tremily.us>
Date: Jan 9, 2014, 00:03 UTC
Message-ID: <20140109000338.GM29954@odin.tremily.us>
In-Reply-To: <CALas-iheQ4Rfxvty5guEieVwa8SffRnhRdHkNXUKwmuHRXD2Xg@mail.gmail.com>

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 [1], 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 [2]. 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 [3]? 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

[1]: http://article.gmane.org/gmane.comp.version-control.git/240164 [2]: http://article.gmane.org/gmane.comp.version-control.git/239968 [3]: 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