On 2 May 2010 17:00, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Jon Seymour <jon.seymour@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html