On Wed, Feb 1, 2012 at 12:56 PM, lkcl luke <[email protected]> wrote:
> On Wed, Feb 1, 2012 at 12:46 PM, Peter Bittner <[email protected]> wrote:
>>
>> The only downside I currently see is we won't have pygit and the
>> mailing list mail app in the same repo, because they are in a separate
>> repo already.
>
> yeahh, that's deliberate - they're separate apps.
>
> hmm... i tell you what - shall i create a new repository that has all
> these things as "submodules"? i only just discovered git submodules -
> they're cool.
>
> you _should_ be able to just have absolutely everything in that one
> repo, hit "make install" and blat, you should have an entire copy of
> the entire pyjs.org web site.
i've done a lot of work with submodules and exotic git configurations,
and imo, submodules are not very flexible. you have to constantly
update the superproject, otherwise you will be checking out
increasingly older copies of the subprojects (not wrong per se [by
design], but clumsy). also, superproject cannot interact with subs at
all.
my favorite configuration so far is one that requires a small amount
of config on the server side, but nothing extra for clients (even
works with old git versions):
.
|-- pyjamas.git
| |-- HEAD
| |-- objects -> ../super.git/objects
| `-- refs -> ../super.git/refs/pyjamas
|-- pyjamasgitweb.git
| |-- HEAD
| |-- objects -> ../super.git/objects
| `-- refs -> ../super.git/refs/pyjamasgitweb
|-- pyjamaslamson.git
| |-- HEAD
| |-- objects -> ../super.git/objects
| `-- refs -> ../super.git/refs/pyjamaslamson
`-- super.git
|-- HEAD
|-- objects
`-- refs
|-- pyjamas
| |-- heads
| | `-- master
| `-- tags
|-- pyjamasgitweb
| |-- heads
| | `-- master
| `-- tags
`-- pyjamaslamson
|-- heads
| `-- master
`-- tags
... i won't go into detail, but i use it right now, successfully, but
for other reasons. all you have to do is disable
gc/garbage-collection in the children, and packed-refs (or symlink
that too, IIRC), so they don't kill the super's objects or have
"phantom branches", respectively
advantages:
) share everything
) each project gets it's own HEAD
) super also gets it's own head (could point to a "how to get started" branch)
) real-time
) push/pull from children OR super project at any time
) push/pull from super without affecting
) allows for interesting collaboration patterns when private repos are
also in play
) [...]
disadvantages:
) requires some specifics wrt / structure
) requires some specifics wrt / .gitignore
) pushing from super works nice ... not without caveats
) super can checkout all projects, but is only ever "aware" of one
) if split, you have to use githooks to keep in sync
) [...]
... of course, gitolite doesn't work like this (but actually, using a
GIT_TEMPLATE it can). the end-result is a superproject that literally
"contains" it's children, eg. a git repo with multiple root-commits.
git is awesome :-)
--
C Anthony
