[responses inline] On Fri, Aug 26, 2016 at 3:37 AM, Dr. Michael Bonert <[email protected]> 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
