Are there any thoughts on managing updates of Mediawiki with git?
I'm not a developer... but I have flirted with the idea a bit. I program occasionally here and there-- though my day job is totally unrelated.
I have played with git and I have a couple of Mediawiki installs that are running from installs via git. I like that I can roll forward and roll back easily.
Updates of the wiki in theory should be: ---- pathofwiki# git checkout 1.26.4 pathofwiki# php maintenance/update.php ----
What is opaque to me is the submodules.
The skins, extensions and external libraries have to be updated with two or three commands... this is missing. I think it stems from gaps in my knowledge about git.
https://www.mediawiki.org/wiki/Download_from_Git#Download_an_extension suggests: --- cd path/to/extensions git pull git submodule update --init --recursive ---
--- If I try the above I get... cd path/to/extensions # git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
--- Branch info # git branch * (detached from 1.26.4) master
--- # git submodule update --init --recursive seems to do nothing
Can someone enlighten me on this or point me to something like "git for amateurs"?
Thanks in Advance, Michael
The latest stable I ran was 1.26.something. I have since flipped over to running the latest wmf branch using strictly git and phabricator. Including ext and skins. So now I run versioning parallel to both mediawiki and wikipedia. I typically lag 1 day behind mediawiki. Yes, there's a couple of extra steps but for me, a single user wiki, I don't have any issues with it.
I do the git action in dir's outside the production root and then copy over to the root after a backup.
The link you reference has, I think, a better path/description for using git under the wmf/branches section. At least that's what connected the dots for me.
Typically when a wmf has been updated, the extensions will also reflect the updated versioning # even if the extension hasn't actually been updated. This is where I use phabricator and update as I want or need.
If your using composer, don't forget to update composer before running /maintenance/update.php else update will fail.
Chap http://wiki.jonesipedia.com/wiki/Special:Version
*********************************************************
On 8/25/2016 11:37 PM, Dr. Michael Bonert wrote:
Are there any thoughts on managing updates of Mediawiki with git?
I'm not a developer... but I have flirted with the idea a bit. I program occasionally here and there-- though my day job is totally unrelated.
I have played with git and I have a couple of Mediawiki installs that are running from installs via git. I like that I can roll forward and roll back easily.
Updates of the wiki in theory should be:
pathofwiki# git checkout 1.26.4 pathofwiki# php maintenance/update.php
What is opaque to me is the submodules.
The skins, extensions and external libraries have to be updated with two or three commands... this is missing. I think it stems from gaps in my knowledge about git.
https://www.mediawiki.org/wiki/Download_from_Git#Download_an_extension suggests:
cd path/to/extensions git pull git submodule update --init --recursive
If I try the above I get... cd path/to/extensions # git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
Branch info # git branch
- (detached from 1.26.4) master
# git submodule update --init --recursive seems to do nothing
Can someone enlighten me on this or point me to something like "git for amateurs"?
Thanks in Advance, Michael
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
[responses inline]
On Fri, Aug 26, 2016 at 3:37 AM, Dr. Michael Bonert michael@librepathology.org wrote:
Are there any thoughts on managing updates of Mediawiki with git?
Personally I think its a great way to manage things. Always nice to keep track of what's changed when running a site.
I'm not a developer... but I have flirted with the idea a bit. I program occasionally here and there-- though my day job is totally unrelated.
I have played with git and I have a couple of Mediawiki installs that are running from installs via git. I like that I can roll forward and roll back easily.
Updates of the wiki in theory should be:
pathofwiki# git checkout 1.26.4 pathofwiki# php maintenance/update.php
Personally I prefer release branches over tags (e.g. git checkout origin/REL1_26 ), although it doesn't matter much.
What is opaque to me is the submodules.
The skins, extensions and external libraries have to be updated with two or three commands... this is missing. I think it stems from gaps in my knowledge about git.
https://www.mediawiki.org/wiki/Download_from_Git#Download_an_extension suggests:
cd path/to/extensions git pull git submodule update --init --recursive
This only applies if you had cloned the giant extensions.git meta-repo, so it doesn't quite apply to what you had described previously where you only had the 1.26.4 tag checked out.
If I try the above I get... cd path/to/extensions # git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
Branch info # git branch
- (detached from 1.26.4) master
# git submodule update --init --recursive seems to do nothing
Can someone enlighten me on this or point me to something like "git for amateurs"?
Thanks in Advance, Michael
So for the release tags (or release branches), they only include core mediawiki. There's two separate ways to include the other stuff.
As separate git repos:
So for installing: (Assuming you've already cloned mediawiki) $ git checkout origin/REL1_26 (If you don't already have composer, you need to install it. Sometimes it will be named composer.phar instead of composer) $ composer install (Note: If you don't like composer, you can do a git clone of mediawiki/vendor.git instead. Just make sure you have the appropriate branch for your version) $ cd extensions $ git clone <extension I want> -b REL1_26 $ git clone <2nd extension I want> -b REL1_26 ... $ cd ../skins $ git clone <skin I want> -b REL1_26 ...
Then to update versions you'd do something like: $ git pull $ git checkout origin/REL1_27 $ composer update $ cd extensions ( and for each extension) $ git pull $ git checkout origin/REL1_27 (and ditto for skins) $ cd ../maintenance $ php update.php
This is slightly simpler than submodules, but the downside is all the components are separate - each skin/extension is separate repo
The submodule system is basically you start off with a checkout of origin/REL1_26, then make your own branch. Then instead of git clone for the extensions you want, you do git submodule add <path to git repo> -b REL1_26. And then git commit your submodule additions in the main git repo. Keep in mind that any time you update a submodule you also have to make a commit in the main git module too. The benefit of using submodules is you can then easily having a testing server and a real server where you make some changes on the testing server, and it only takes 2 commands ( git pull && git submodule update ) to transfer your changes from the testing server to the production server.
-- bawolff
Ok oraid
2016 rgp. 27 00:46 "Brian Wolff" bawolff@gmail.com rašė:
[responses inline]
On Fri, Aug 26, 2016 at 3:37 AM, Dr. Michael Bonert michael@librepathology.org wrote:
Are there any thoughts on managing updates of Mediawiki with git?
Personally I think its a great way to manage things. Always nice to keep track of what's changed when running a site.
I'm not a developer... but I have flirted with the idea a bit. I program occasionally here and there-- though my day job is totally unrelated.
I have played with git and I have a couple of Mediawiki installs that are running from installs via git. I like that I can roll forward and roll back easily.
Updates of the wiki in theory should be:
pathofwiki# git checkout 1.26.4 pathofwiki# php maintenance/update.php
Personally I prefer release branches over tags (e.g. git checkout origin/REL1_26 ), although it doesn't matter much.
What is opaque to me is the submodules.
The skins, extensions and external libraries have to be updated with two or three commands... this is missing. I think it stems from gaps in my knowledge about git.
https://www.mediawiki.org/wiki/Download_from_Git#Download_an_extension suggests:
cd path/to/extensions git pull git submodule update --init --recursive
This only applies if you had cloned the giant extensions.git meta-repo, so it doesn't quite apply to what you had described previously where you only had the 1.26.4 tag checked out.
If I try the above I get... cd path/to/extensions # git pull You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details.
git pull <remote> <branch>
Branch info # git branch
- (detached from 1.26.4) master
# git submodule update --init --recursive seems to do nothing
Can someone enlighten me on this or point me to something like "git for amateurs"?
Thanks in Advance, Michael
So for the release tags (or release branches), they only include core mediawiki. There's two separate ways to include the other stuff.
As separate git repos:
So for installing: (Assuming you've already cloned mediawiki) $ git checkout origin/REL1_26 (If you don't already have composer, you need to install it. Sometimes it will be named composer.phar instead of composer) $ composer install (Note: If you don't like composer, you can do a git clone of mediawiki/vendor.git instead. Just make sure you have the appropriate branch for your version) $ cd extensions $ git clone <extension I want> -b REL1_26 $ git clone <2nd extension I want> -b REL1_26 ... $ cd ../skins $ git clone <skin I want> -b REL1_26 ...
Then to update versions you'd do something like: $ git pull $ git checkout origin/REL1_27 $ composer update $ cd extensions ( and for each extension) $ git pull $ git checkout origin/REL1_27 (and ditto for skins) $ cd ../maintenance $ php update.php
This is slightly simpler than submodules, but the downside is all the components are separate - each skin/extension is separate repo
The submodule system is basically you start off with a checkout of origin/REL1_26, then make your own branch. Then instead of git clone for the extensions you want, you do git submodule add <path to git repo> -b REL1_26. And then git commit your submodule additions in the main git repo. Keep in mind that any time you update a submodule you also have to make a commit in the main git module too. The benefit of using submodules is you can then easily having a testing server and a real server where you make some changes on the testing server, and it only takes 2 commands ( git pull && git submodule update ) to transfer your changes from the testing server to the production server.
-- bawolff
MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org