Re: RFD: a submodule-like facility that tracks branches rather than commits

[Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>]

On 2 May 2010 17:00, Junio C Hamano <gitster@pobox.com> wrote:
> Jon Seymour <jon.seymour@gmail.com> writes:
>
>> Has consideration ever been given to a submodule-like facility where
>> the configuration information maintained in the supermodule for the
>> submodule is not a gitlink but is instead the name of a branch (or
>> generally, a symbolic reference within the nested submodule).
>
> I think this comes up from time to time, and there was an even a slightly
> more concrete suggestion to us 0{40} in the tree object to denote such an
> entry.
>
> But once people realize that there is no single canonical authoritative
> repository whose branch heads point at the same commits for everybody in a
> distributed environment, the line of thought to touch gitlink entries gets
> retracted or discarded as a misguided idea.
>
> I however don't think it would hurt to enrich .gitmodules with not just
> the repository information but with branch information to help clones
> decide which commit (other than what is recorded in the tree of the
> superproject's commit) on the named remote tracking branch to try out with
> the superproject's commit.
>


Gnome uses jhbuild to build out of git, tarballs and other vcs's. It
has quite a bit of code of recursivly finding & updating all
submodules to the latest tip.

This is want you generally want when you integrate.

When you actually want to lock on a particular revision and not track
upstream branches I believe subtree merge strategy should be used
instead of submodules.

I beleive you should be able to specify symbolic references for the
git submodule to store.