On May 4, 2009, at 11:14 AM, C. Titus Brown wrote:
> > On Mon, May 04, 2009 at 06:54:30AM -0700, Istvan Albert wrote: > -> On May 4, 9:43?am, "C. Titus Brown" <c...@msu.edu> wrote: > -> > -> > Yes, thanks... but can you do it multiple times? ?There's no > 'fork' > -> > button under cjlee112's pygr repo for me. > -> > -> ah I guess it may not be possible to fork multiple times. > > Right, it is not. I don't know what you mean by "fork multiple times". My pygr repo is not a fork of anything, so your creating a fork of my pygr repo would not constitute "multiple forks". I suspect you can't create a fork of my "pygr" repo simply because you *already* have a repo called "pygr". Since a fork is always given the same name as the parent, that would create a name collision in your case... I think you should rename your current "pygr" repo to something like "pygr_old"... more details below. > > > Chris, in light of this, you could arrange things with two independent > repos: > > pygr/ -- the pygr tree that we all fork from > pygr-master/ -- a separate repo, with no direct github relationship > to the pygr repo, to which you push "accepted" changes > and which contains all of the version branches, etc. > > Does that make sense? ?? The "pygr" repository I've already created will serve that "official repository" role; its master branch will contain only final "accepted changes". People will be able to fork from that repository on github, and get the latest updates from the official master branch as simple as "git pull upstream/master". If I (or anyone else) need to collaborate with someone else on an experimental branch (e.g. seqdb_review), I and you (and whoever else wants to) can each add that experimental branch to our github repository and pull from each other using github's nice tools. Git will let us create as many experimental branches as our brains can keep track of. Unless I'm missing something basic here, it looks like that provides all the types of flexibility we're going to need. I don't see a need for an additional "pygr-master" repo. > > > We can also talk with github about creating a 'pygr' account, if you > like. Again, I don't see a need. Can you describe a specific usage case for this that I am forgetting? > > > -> forgot to mention, you can rename your fork under the admin tab. > > great, thanks! I suggested that you rename your current "pygr" repository something like "pygr_old", then try again to create a fork of my pygr repository. Then you can copy the branches that we want to keep from "pygr_old" to your new "pygr" fork. If that goes well, eventually you could delete the "pygr_old" repository (once you've used the new fork for quite a while and are fully satisfied it contains all the branches that are worth keeping)... I am enjoying the much cleaner and easier pattern of synch'ing of following github's model, and look forward to being able to work with collaborators via github forks. -- Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" group. To post to this group, send email to pygr-dev@googlegroups.com To unsubscribe from this group, send email to pygr-dev+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
