Jason Grout <jason-s...@creativetrax.com> writes: > On 2/28/12 7:04 PM, David Roe wrote: >> Is there an easy way to collaborate on an experimental set of patches on >> top of Sage? The sage-combinat model is very close to what I'm looking >> for, but it seems difficult to set up all the infrastructure: we have to >> have a server analogous to http://sage.math.washington.edu:2144/, set up >> the initial repositories correctly.... Is there an easier way for a >> project with only a couple people? Is there a nice way to do this with >> Sage on github? > > You took the words right out of my mouth. Just fork Sage on github. > Then you can submit pull requests to each other, designate one > person's branch as the "blessed" branch, and coordinate from there. > > I'd say git and github is your ticket to ride.
+1, you are most welcome to use the sagemath/sagelib repo on github! I find the sage-combinat patch queue a little bit terrifying, to be honest, but maybe that's just me. However, please do keep in mind that the sagemath/sagelib repo on github is just following Jeroen's Sage Library SPKGs right now. As such, I have no control over what commits go into it. Therefore, when we eventually move to git, the git repo we use might look pretty different from what github:sagemath/sagelib is right now. I might need to delete it and start over with a new git repository, or at least perhaps delete some branches, depending on what exactly we decide to do during the switchover. At that point you may need to do some hairy stuff with git to get your commits into the new repo. I will of course try to avoid doing this, but I can make no guarantees. William already ran into an inconvenience when I had to rewrite some history on the repo and then bug him about rebasing some of his commits. If you're fully proficient with git I'm sure you can keep up, though. Technical details of the current situation follow, for those who know more about git and/or DVCS. ---- Jeroen creates each new development release by applying a string of positively reviewed patches to the previous stable release, rather than applying *newly* positively reviewed patches to the previous development release. Thus the history tree of sagemath/sagelib on github looks like a bunch of stable releases along one branch (named "release") and a bunch of branches splitting from it at intervals and containing substantial repetition of commits from the "release" branch. These abortive branches will never be merged into the main trunk by Jeroen, but will just sit there. I intend to eventually *delete* them, once we move to git. So you will have to do rebasing and *not* merging, for now, if you want to produce patches that can be submitted on trac, and if you want to avoid having upstream commits in your local history which have been deleted by upstream (me). However, once we switch to git, I would encourage you to merge rather than rebase. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
