Sorry got=git. It's the price I pay for typing this on my iphone. On Friday, December 20, 2013, Gregory Casamento wrote:
> There are a lot of things which make got a very attractive option. I would > support a move to git only if everyone on the project feels comfortable > with doing so. > > It's important to remember that gna and savannah both support git at the > moment. GitHub is also an option. > > One of the reasons I maintained the mirror was so that if we ever decided > to make the switch it would be essentially a zero effort move. > > The repositories on GitHub were one way mirrors but I had code in my > scripts that would migrate changes made on the for side back to svn. The > only person who has direct access to that repo was me so it was > experimental. > > If anyone knows of a set if scripts which can maintain such a mirror I > would be interested. For the gnustep mirror I had to write my own. > > Greg > > On Friday, December 20, 2013, Markus Hitter wrote: > >> Am 20.12.2013 17:27, schrieb Dr. H. Nikolaus Schaller: >> > There would be the Linux way of handling patches. >> > >> > 1. people clone the central repository (and pull from time to time) >> > 2. they develop patches in whatever (local) branches they like to >> > 3. if a patch is working for them, they git-format-patch and post it to >> > the mailing list >> > 4. the (a) maintainer picks up the patch and tries to apply with >> > git am file.patch to a local branch >> > 5. if ok, the maintainer makes a push to github and it is "accepted" >> >> Yes, this should work. Git is tailored for this approach, after all. >> >> What I currently experiment with is to hand out write access very >> liberately, asking people to commit to their own branch(es), only. Works >> well, the number of branches isn't limited, after all. The not so good >> thing here is, people aren't used to it. The good things are, >> contributions are very visible, people have to just git-push to make >> their work an acutal contribution, it's easy to apply contributions >> partially, to review them and to keep them from bitrotting by rebasing. >> >> Merges no longer happen, instead these branches are rebased towards the >> current top of the development/experimental branch, then cherry-picked. >> When things look good, chunks from experimental are picked over to >> master, too. You get a very tree-like appearance of the whole repo with >> all the branches moving skywards together, keeping history on the >> single-string master branch. This makes bisecting very simple. >> >> >> Markus >> >> -- >> - - - - - - - - - - - - - - - - - - - >> Dipl. Ing. (FH) Markus Hitter >> http://www.reprap-diy.com/ >> http://www.jump-ing.de/ >> >> _______________________________________________ >> Discuss-gnustep mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnustep >> > > > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > http://www.gnustep.org > http://heronsperch.blogspot.com > -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) http://www.gnustep.org http://heronsperch.blogspot.com
_______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
