On Tue, Oct 23, 2012 at 10:57:57PM +0200, Jens Lehmann wrote:
> Am 22.10.2012 14:37, schrieb W. Trevor King:
> > 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.

And that's the problem I'm trying to solve ;).

> > 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?

That makes sense, however the problem is not in the common content, it
is in the final index:

  index
  |-- sub-site a (branch of sub-site-x)
  |-- sub-site b (branch of sub-site-x)
  `-- sub-site c (branch of sub-site-x)

All of the sub-sites are branches of a single sub-site-x master:

  o--o--o--o   sub-site-x
   \--o--o--o  sub-site-1
       \--o    sub-site-2
        \--o   sub-site-3

So they all live in the same repository.  My index repository will
have submodules for each of the sub-sites, and I'd like the index
branch to *also* live in same repository as the subsites.  This last
bit is the sticky part.

For a proof-of-concept example (where I currently use public
repositories for the sub-site submodules), see

  http://wking.github.com/swc-workshop/

which uses gh-pages as the index branch, and master, 2012-10-caltech,
and 2012-10-lbl for the sub-site branches.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy