On Sun, Feb 19, 2012 at 9:38 PM, Keshav Kini <keshav.k...@gmail.com> wrote: > William Stein <wst...@gmail.com> writes: >> Hi Keshav (/Sage-devel), >> >> I want to switch to using git to develop the core Sage library (though >> I'll still submit patches using hg for now). >> How can I do this? > > Hi William, > > Just fork sagemath/sagelib on github, then do > > $ cd $SAGE_ROOT/devel/ > $ git clone g...@github.com:williamstein/sagelib sage-git > $ rm sage > $ ln -S sage-git sage > $ cd sage
Cool -- that's actually exactly what I had done before sending the email, thinking it was the natural thing to do. https://github.com/williamstein/sagelib In general, what version of the Sage library is at sagemath/sagelib on github? > $ git remote add upstream g...@github.com:sagemath/sagelib > $ sage -b > > Everything should just work from this point. To generate a patch from > one of your branches will be a little bit more work, but first do this: > > $ cd $SAGE_ROOT/devel/sage > $ git remote update upstream > $ git diff upstream/master <your branch> > foo.patch > > I am making sure that upstream/master always points to the latest > development release, or stable release if there have been no development > releases since the last stable release. Ah, yes, that answers my main question. > > Finally you'll need to add in some lines at the top of foo.patch, viz. > > # HG changeset patch > # User William Stein <wst...@gmail.com> > # Date $(date +%s) 0000 > commit message for entire patch > > Here $(date +%s) of course should be expanded by the shell. You can > probably write a quick shell script to insert these lines automatically, > maybe accepting the commit message as an argument. (I assume of course > that you will be consolidating multiple small commits into one patch, > which hopefully we won't have to do anymore once we actually switch to > git.) > > Hope that helps. Evidently other people in this thread do not know that > I have been maintaining a git version of the Sage library, so hopefully > it will help them too, if they're interested :) Thanks!! In particular, could you give me a step-by-step handholding explanation of how would I replicate (and improve on!) the following HG workflow: 1. Decide I want to do something awesome. 2. Create a trac ticket describing it. 3. Write code. 4. Post a single patch 5. Rewrite code. 6. Post a single updated patch. With queues I do "hg qinit trac12345.patch", etc, and "hg qrefresh" and "hg export". I would like to improve on this of course by being able to record (at least for my personal edification) lots of commits, even if they get folded later for the public. -- William > > -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 -- William Stein Professor of Mathematics University of Washington http://wstein.org -- 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
