You can still add collaborators to public repos. People usually do this for "project members" that they trust to maintain the "pristine" repo/branch. Depending on how you approach things you might not even use pull requests. If your network is small you can just watch forks. If it's huge, like Rails', you might turn on the autoresponder and handle pull requests/patch submission somewhere else completely, like your issue tracker.
On Thu, Apr 9, 2009 at 1:32 PM, Tchalvak <[email protected]> wrote: > > Also, I guess adding collaborators is more the private repo way of > doing things, whereas forking cleanly makes more sense when dealing > with a public repo, since you don't have the space constraints and the > like. > > On Apr 9, 3:24 am, Tekkub <[email protected]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
