[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mediawiki-l
Subject:    Re: [MediaWiki-l] Managing updates of Mediawiki with git (?)
From:       Jurij Byrda <gintasgp19 () gmail ! com>
Date:       2016-08-26 22:30:12
Message-ID: CAFeHCT_fi59OGh1-8_b14idBiZLC3m1m52hzi8DpFKeO+DJFXw () mail ! gmail ! com
[Download RAW message or body]

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 mailing list
To unsubscribe, go to:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

[prev in list] [next in list] [prev in thread] [next in thread]