With git you wouldn't have to compromise the stability of MediaWiki's head revision. You could review patches while they are only committed to the patch-writers own local git repository. When you are ready to accept the patch into trunk you do.
A major benefit of this model is that you could have the head revision be defined as the code that is running live on the sites.
git makes it very easy to switch from svn and has lots of svn-compatibility features, including automatically importing your svn repositories, etc.. It has a lot of other benefits as well such as speed (owing in part to the history being on your machine) but the true benefit for MediaWiki is the distributed development model. There is no reason to sacrifice the sanctity of your head just because someone *thinks* their code is ready.
/Brian
I was actually going to bring this up the other day, and ask if there was going to be a switch to git. I completely agree that mediawiki development could benefit greatly from the way git handles branches.
-Adam
On Jun 28, 2009, at 1:17 PM, Brian wrote:
With git you wouldn't have to compromise the stability of MediaWiki's head revision. You could review patches while they are only committed to the patch-writers own local git repository. When you are ready to accept the patch into trunk you do.
A major benefit of this model is that you could have the head revision be defined as the code that is running live on the sites.
git makes it very easy to switch from svn and has lots of svn- compatibility features, including automatically importing your svn repositories, etc.. It has a lot of other benefits as well such as speed (owing in part to the history being on your machine) but the true benefit for MediaWiki is the distributed development model. There is no reason to sacrifice the sanctity of your head just because someone *thinks* their code is ready.
/Brian
This idea is so crazy that it has no merit and is not even worth discussing <insert because>.
On Sun, Jun 28, 2009 at 5:00 PM, Adam Meyer meyer7@mindspring.com wrote:
I was actually going to bring this up the other day, and ask if there was going to be a switch to git. I completely agree that mediawiki development could benefit greatly from the way git handles branches.
-Adam
On Jun 28, 2009, at 1:17 PM, Brian wrote:
With git you wouldn't have to compromise the stability of MediaWiki's head revision. You could review patches while they are only committed to the patch-writers own local git repository. When you are ready to accept the patch into trunk you do.
A major benefit of this model is that you could have the head revision be defined as the code that is running live on the sites.
git makes it very easy to switch from svn and has lots of svn- compatibility features, including automatically importing your svn repositories, etc.. It has a lot of other benefits as well such as speed (owing in part to the history being on your machine) but the true benefit for MediaWiki is the distributed development model. There is no reason to sacrifice the sanctity of your head just because someone *thinks* their code is ready.
/Brian
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
just because someone *thinks* their code is ready.
By the way, a lot of pain could be reduced if commiters would first double check their code with $ php --syntax-check before committing. Or maybe it should be made automatic.
mediawiki-l@lists.wikimedia.org