discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Repositories


From: Gregory Casamento
Subject: Re: Repositories
Date: Fri, 20 Dec 2013 18:48:45 -0500

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
Discuss-gnustep@gnu.org
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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]