On Tue, Mar 22, 2011 at 7:28 AM, <in-gitvger@xxxxxxxx> wrote: > > In message <AANLkTikv+Wf_nSt0GZj0WgPjpbk6Kr_WG-ueO6US9bUM@xxxxxxxxxxxxxx>, 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 > My current setup is that I'm simply versioning my home directory with mercurial. Some vim plugins are under git and since it's a different version control system I can check in the plugins easily. When I need to update those plugins, I just run git update, and check them into mercurial again. No problem, very easy. I'm looking into what it would take to convert my repo to be completely git, and so far I have no exact way of dealing with those vim plugins since via submodules I have to rely on the external repos being present when I clone my homedir repo. Granted, if the repos have gone away a decade from now and my vim plugins are not present, it won't be the end of the world, but I want to see how close I can get to my current functionality when using git instead of mercurial. -- 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