From: Dmitrijs Ledkovs Date: Sun, 02 May 2010 16:04:35 GMT Subject: Re: RFD: a submodule-like facility that tracks branches rather than commits Message-ID: In-Reply-To: <7veihuuwdj.fsf@alter.siamese.dyndns.org> On 2 May 2010 17:00, Junio C Hamano wrote: > Jon Seymour 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.