On Thu, Jun 4, 2009 at 11:19 PM, Daniel Spiewak <djspie...@gmail.com> wrote:
> > I reforked assaf/buildr from apache/buildr. I also renamed the older fork > > buildr-old, so that fork (and its network) are still around, just no > longer > > maintained. > > > Still working on this with my repo. GitHub's deletion queue apparently > glitched (they're working on it). > > > > Preferably, fork from a mainline repo not a personal repo, i.e. fork > > apache/buildr not assaf/buildr. We want to build the network around the > > Apache Buildr project. Git (unlike SVN) handles multiple repositories > with > > breeze, so you can still pull (and push) to other people's repos. > > > Personally, I don't think we should be shy about forking off of each other. > Well, I take that back, the *committers* should almost certainly fork off > of > apache/buildr; but the rest of the community shouldn't feel so constrained. > GitHub puts all the forks transitively in the same network, so there really > isn't too much of a difference. > > The advantage to unrestricted forking is it allows non-committers more > freedom in what they can work on. For example, I like to work on some more > experimental stuff in my fork. A lot of it isn't ready yet, so I haven't > pushed it into the SVN. Someone might get interested in this and decide to > help out with that particular feature. The most logical thing for them to > do would be to fork *my* repository and procede from there. GitHub would > notify me of their commits, and I could pull them into my (still unstable) > fork pending eventual release into the trunk/. If said non-committer had > forked off of apache/buildr, we would have had to have the whole > fork/integration process over email or on JIRA. I'm not saying that these > aren't appropriate venues, but I think that it is only logical to leverage > some of the tools GitHub allows us in those sorts of situations. And what happens if they get interested in one of my experimental branches? Delete the repository and refork? Github allows you to send pull requests to anyone on the network, including peers. So if they forked apache/buildr, they can still send a pull request to you, and you can see their changes in the fork queue. I like using Github, but I don't like being limited by Github. Fortunately, GIt is even better and you can pull from any remote repository, not just those in your network. For example, since I added your repo a while back, I can do this: $ git branch -r . . . djspiewak/clojure djspiewak/cobertura djspiewak/commands djspiewak/gae djspiewak/interactive-shell djspiewak/jruby-system djspiewak/master djspiewak/scala-joint-compilation djspiewak/scalabison djspiewak/separate-scala-specs Without forking it I can follow all your experimental branches, branch off yours, merge your changes to trunk, and ask you to pull from my repository. Assaf > > I think that, in the end, everything has and will continue to center around > apache/buildr, which is basically the SVN. No feature is really "blessed" > until it gets into the trunk/, so it's hard to imagine development > diverging > too far. If someone were to go wildcat with their fork, then they would > most likely be the sort of person who would be forking even if Apache > didn't > provide Git mirrors. > > Daniel >
