From: W. Trevor King <wking@tremily.us>
Date: Thu, 09 Jan 2014 00:03:38 GMT
Subject: Re: [RFC v2] submodule: Respect requested branch on all clones
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