There's no reason for you to try to manage collaborators, that's exactly
what forks are for. I think you'll also find that if you put a public repo
up that people want to contribute to they're just going to fork, they're not
going to ask you for a collab on the base repo, even if you ask them to.
There's not much point in doing a "dirty" fork either, you can simply keep
two branches in your base repo, one for "pristine" (usually master) and one
for accepted changes that aren't yet fully tested (your "dirty", some call
it "staged" or "next").
It can be hard at first to embrace such a different workflow, but I think
you'll find it so much easier when you don't have to manage permissions and
collaboration, and instead just pull in changes and worry only about your
own repo.
Tekkub
GitHub General Support
http://support.github.com/
Join us on IRC: #github on freenode.net
Discussion group: [email protected]
On Thu, Apr 9, 2009 at 1:17 AM, Daniel Stockman
<[email protected]>wrote:
>
> I would think forks with pull requests would be quite sufficient to
> maintain such a "core" repository. Alternatively, you could create a
> "dirty" branch, but then the problem still remains how to propagate
> commits (without adding tons of collaborators).
>
> And really, there's very little "inefficiency" in forking a repo on
> Github. It's practically trivial, compared to saurian VCSes such as
> SVN and CVS (shudder). It really doesn't get any simpler than forks
> and pull requests (for both you and the contributors).
>
> ~ Daniel
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
