Re: [Labs-l] Sharing code in GitHub
I pushed three repos just now[1][2][3], and I'm not sure about the correct way to deal with others. One of them contains some counter vandalism functionality, and I fear that publishing them makes vandals easier to bypass it somehow. Another one is basically a MediaWiki core repo, with a few patches on top of master to support [1]; I'm afraid pushing it will upload a full MediaWiki history. [1] https://github.com/liangent/mediawiki-extensions-Labs [2] https://github.com/liangent/mediawiki-maintenance [3] https://github.com/liangent/updatedyk -Liangent On Sat, May 17, 2014 at 3:04 AM, Emilio J. Rodríguez-Posada emi...@gmail.com wrote: Hi all; I use to publish my scripts with open source licenses. Previously I used SVN, but now I have moved to GitHub. This is my collection of repositories.[1] I have uploaded some of my tools (still migrating more from Toolserver) and started a special repo for code chunks of mine that can be widely used by other coders.[2] By now, only one about how to run a query over all Wikimedia projects[3] but I will add more. Please share your GitHub repo, I would like to follow you and read your code. :-) Regards [1] https://github.com/emijrp [2] https://github.com/emijrp/wmflabs [3] https://github.com/emijrp/wmflabs/blob/master/queryalldb.py ___ Labs-l mailing list Labs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/labs-l ___ Labs-l mailing list Labs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/labs-l
Re: [Labs-l] Sharing code in GitHub
(anonymous) wrote: I pushed three repos just now[1][2][3], and I'm not sure about the correct way to deal with others. One of them contains some counter vandalism functionality, and I fear that publishing them makes vandals easier to bypass it somehow. Another one is basically a MediaWiki core repo, with a few patches on top of master to support [1]; I'm afraid pushing it will upload a full MediaWiki history. [1] https://github.com/liangent/mediawiki-extensions-Labs [2] https://github.com/liangent/mediawiki-maintenance [3] https://github.com/liangent/updatedyk [...] I don't know if GitHub shares commits over all repositories to minimize uploads, but if you would clone such a MediaWiki add-on, you could optimize the download by using the --reference option à la: | git clone --reference /local/mediawiki remote:/mediawiki-add-on /local/mediawiki-add-on This will only download the commits from the remote reposi- tory that aren't part of the local repository (for native Git protocols; http repositories usually won't be fine- grained enough). This isn't that useful when you just need to initialize a new working directory every three months, but can save quite some time for example when you regularly run a test suite and/or you have submodules with remote URLs (then git submodule update --reference Co.). Tim ___ Labs-l mailing list Labs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/labs-l
Re: [Labs-l] Sharing code in GitHub
On Fri, May 16, 2014 at 10:44 PM, Tim Landscheidt t...@tim-landscheidt.de wrote: (anonymous) wrote: I pushed three repos just now[1][2][3], and I'm not sure about the correct way to deal with others. One of them contains some counter vandalism functionality, and I fear that publishing them makes vandals easier to bypass it somehow. Another one is basically a MediaWiki core repo, with a few patches on top of master to support [1]; I'm afraid pushing it will upload a full MediaWiki history. [1] https://github.com/liangent/mediawiki-extensions-Labs [2] https://github.com/liangent/mediawiki-maintenance [3] https://github.com/liangent/updatedyk [...] I don't know if GitHub shares commits over all repositories to minimize uploads, but if you would clone such a MediaWiki add-on, you could optimize the download by using the --reference option à la: | git clone --reference /local/mediawiki remote:/mediawiki-add-on /local/mediawiki-add-on This will only download the commits from the remote reposi- tory that aren't part of the local repository (for native Git protocols; http repositories usually won't be fine- grained enough). This isn't that useful when you just need to initialize a new working directory every three months, but can save quite some time for example when you regularly run a test suite and/or you have submodules with remote URLs (then git submodule update --reference Co.). I haven't reviewed the repos in question but if they're closely related to existing core branches then why not just store in the core repo? (or alternatively on github in a fork of core) https://www.mediawiki.org/wiki/Gerrit/personal_sandbox -Jeremy ___ Labs-l mailing list Labs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/labs-l
