On Wed, Feb 29, 2012 at 4:51 PM, Keshav Kini <keshav.k...@gmail.com> wrote: > William Stein <wst...@gmail.com> writes: >> Amazingly, after all we went through, I still have a messed up repo >> (no master branch). Sigh. >> >> deep:d wstein$ git branch >> 12594 >> github-master >> lfun >> * trac_8393 >> >> I guess I should just start over. > > You almost never need to start over with git. Just `git fetch` from > upstream, create a master branch, check it out, and `git reset <commit>` > where <commit> is wherever you want master to be pointing. > >>> Yes, it is pretty >>> terrible right now, but that's because we're using patches (not really >>> because they are in hg format). Fetching from other git repos to do >>> reviews is much, much easier :) >> >> It's difficult for me because they are patch in hg format, but I can't >> export a patch out of git in hg format. It's possible to import the >> code in from the trac ticket, but then if I make changes I have to >> export them as a git diff, then import them into another hg repo, then >> export them again. As far as I can tell -- no easy way to referee a >> trac ticket right now using git. I bet it would be possible for a >> git wizard to setup some scripts to make this easy. I think doing >> so is an important first step toward moving Sage developers to git. > > I see that as a waste of time. We should create scripts to facilitate a > new workflow, not the old one. The average Sage developer should not be > encouraged to use git just yet, I think. That is because, as you have > noticed, it is downright painful to use git to work on Sage right now. > Basically the only advantage right now is the ease of collaboration, > which Jason mentioned above. > > But the solution is not to create scripts that automate this painful > process. What we need to do is set up an infrastructure to support a > git-based workflow, not create scripts that dumb git down to support our > current workflow. (This will be covered in the Workflow SEP.)
+1 (I do think we should have scripts and/or a sage command so the average developer doesn't even have to know that git (or whatever else we are settling on) is being used under the hood to submit new code and review/extend submitted code. They should be clearly defined in terms of git commands, so the semi-advanced user can use git directly with little/no hassle.) As for issue tracking, I've heard a lot of complaints about the github one (especially before they launched their new system) and my only comment here is while it's nice to have issue tracking and source code repositories synchronized, there's no need to do so as long as we can link between the two (e.g. use standard naming conventions) Certainly using trac as a transient source code repository is rather ugly. - Robert -- 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
