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

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>
Date: May 2, 2010, 16:04 UTC
Message-ID: <q2j86ecb3c71005020904kf543e987s19cd396ef672bd79@mail.gmail.com>
In-Reply-To: <7veihuuwdj.fsf@alter.siamese.dyndns.org>

On 2 May 2010 17:00, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> 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.