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, 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
More majordomo info at

Reply via email to