Am 22.10.2012 14:37, schrieb W. Trevor King: > I have a bunch of branches in my repo (a, b, c, …), and I'd like to > check them out into subdirectories of another branch (index). My > initial inclination was to use something like > > $ git checkout index > $ git branch > a > b > c > * index > $ git submodule add -b a --reference ./ ./ dir-for-a/ > $ git submodule add -b b --reference ./ ./ dir-for-b/ > $ git submodule add -b c --reference ./ ./ dir-for-c/ > > but cloning a remote repository (vs. checking out a local branch) > seems to be baked into the submodule implementation. Should I be > thinking about generalizing git-submodule.sh, or am I looking under > the wrong rock? My ideal syntax would be something like > > $ git submodule add -b c --local dir-for-c/ But then we'd have to be able to have two (or more) work trees using the same git directory, which current submodule code can't. > The motivation is that I have website that contains a bunch of > sub-sites, and the sub-sites share content. I have per-sub-site > branches (a, b, c) and want a master branch (index) that aggregates > them. Perhaps this is too much to wedge into a single repository? To me this sounds upside-down. I'd put the three sub-sites into different repositories and the shared content into a submodule that all three sub-sites use. At least that is how I do all my content sharing on the websites I have done ... does that make sense? -- 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