From: in-gitvger@baka.org
Date: Tue, 22 Mar 2011 14:28:10 GMT
Subject: Re: dependable submodules
Message-ID: <201103221428.p2MESAkG018553@no.baka.org>
In-Reply-To: <AANLkTikv+Wf_nSt0GZj0WgPjpbk6Kr_WG-ueO6US9bUM@mail.gmail.com>


In message <AANLkTikv+Wf_nSt0GZj0WgPjpbk6Kr_WG-ueO6US9bUM@mail.gmail.com>, Dani
el writes:

    I tried git-subtree. thanks but this is not what I wanted. This
    removed the .git dir for the subtree and hence updating the subtree is
    not easy.

    I want the functionality of git submodule except that I don't want the
    version checked in as part of the superproject to have to be fetched
    remotely.

Could "remotely" be a local shadow master?  gitslave is another option
to git-submodules and git subtree merge for provide a superproject
with attached slaves, but like git submodules it does require fetching
from "upstream".  However, there is nothing requiring that "upstream"
be the true Internet upstream.  It could be a local shadow copy of the
master.  I describe this scenario in more detail on the gitslave home
page starting with the third paragraph under "Gitslave is not
perfect".  I wrote this with gitslave in mind, but there is nothing
stopping you from using the concept with git-submodules (aside from
the pain of the submodule update pain added to the shadow repository
update pain breeding).

However, if you really really have a good reason to want *everything*
in one repo, perhaps you could play games with branches and subtree
merge.  For each slave repository, create a new branch with the
content you want (or do a merge from the slave onto the new branch to
get the history or whatever).  Then attach the local repository to
itself using git-submodules (bonus points if you can use a
repository-relative URL), set the correct SHA corresponding to the
branch of the "slave", and then (if it works, and I don't see why it
would not) you are all done.  I would hate to have to use and update
such a repository, though.

					-Seth Robertson