Git submodule for a local branch?

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/

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?

Cheers,
Trevor

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

On Mon, Oct 22, 2012 at 08:37:14AM -0400, W. Trevor King wrote:

but cloning a remote repository (vs. checking out a local branch)
seems to be baked into the submodule implementation.

Perhaps --local would set submodule.$name.url to '.', and ome
combination of GIT_WORK_TREE, GIT_DIR, and object references could be
used to setup and manage the local submodule.

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

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?

On Tue, Oct 23, 2012 at 10:57:57PM +0200, Jens Lehmann wrote:

Am 22.10.2012 14:37, schrieb W. Trevor King:

quoted

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 ;).

quoted

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