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
signature.asc
Description: OpenPGP digital signature
