Talk:Download from Git

Keeping up to date

After the line starting with 'If you're using a particular branch ...', the text provides the command

git pull

At least for MSysGit (Windows portable Git version) picking up the latest changes after switching to a particular release branch, it needs to be

git pull https://gerrit.wikimedia.org/r/p/mediawiki/core.git REL<release number>

After updating the repository, especially after switching to a particular release branch, I have to clean the local repository:

git clean -df -e extensions -f -q -x

I have no linux to compare with, therefore I did not add this to the article. Surak ^Talk 06:42, 5 August 2012 (UTC)

Using a forced git-clean is rather risky as it might also delete your LocalSettings.php and uploaded user files. Be careful with that.

Using git-clean should not be necessary. And for extensions the same process applies (use git pull). Krinkle (talk) 03:44, 7 August 2012 (UTC)

Git pull should work just fine. Switching to a different release branch involves a few more commands than just git pull. But if you're using the "master" branch or the "REL1_19" branch and want to update it to the latest version within that branch, a pain "git pull" will work just fine.

Note that very few commits are made to a REL* branch after the first release (only minor releases). To checkout a new branch all you need to do fetch the data, create a new remote-tracking branch and check it out.

jdoe:/srv/example/mediawiki (REL1_18)$ git fetch && git branch REL1_19 -t origin/REL1_19 && git checkout REL1_19
jdoe:/srv/example/mediawiki (REL1_19)$

Using git-pull with an absolute url will also work but has side-effects.

Note that this is only needed when doing major upgrades from branch to branch. To update to the latest remote version of the branch you're already on, plain "git pull" will do. Krinkle (talk) 03:52, 7 August 2012 (UTC)

Suppose I upgrade MediaWiki to the latest stable release (in this case, v1.20.1). If I use git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions/<EXT>.git there's a possibility that this latest development version of the extension will use features (e.g. hooks) that are only available in the alpha version of MediaWiki (in this case, v1.21), and therefore it might not work, right? Or would it probably be backward-compatible? I was going to do that with all my extensions. Thanks, Leucosticte (talk) 12:38, 30 November 2012 (UTC)

How to set extension version to MW version?

How do I find the dependencies between core and extensions? If e.g. I choose REL1_19 for MediaWiki core, how do I set the extension to the same level? I did not find any reagrding branches or tags, neither in 'extensions', nor within single submodules. Surak ^Talk 06:46, 5 August 2012 (UTC)

Extensions use the same branching scheme as MediaWiki core. So if you use MediaWiki 1.19.x, use the REL1_19 branch of the extensions.

Most extensions in Git do not have branches yet, because they were migrated to Git after MediaWiki 1.19 was released and MediaWiki 1.20 is still in development. The branches for older versions are only in SVN.

See for example Extension:Cite and Special:ExtensionDistributor/Cite. Krinkle (talk) 04:14, 7 August 2012 (UTC)

Error

After try to update the extensions path i receive this message:

fatal: reference is not a tree: beb9db28aaec486c8f00f4e03613410dbea6dada Unable to checkout 'beb9db28aaec486c8f00f4e03613410dbea6dada' in submodule path 'Nonlinear'

Any sugestions? @lestaty ^discuţie 13:16, 8 September 2012 (UTC)

Update error

When I want to update all extensions, I get an error.

sh-4.1$ git submodule update --init
fatal: reference is not a tree: 655d019b84689e37b3fb1018600f629c657fb575
Unable to checkout '655d019b84689e37b3fb1018600f629c657fb575' in submodule path 'Persona'
sh-4.1$</pre>

Anyone can help me with this? [[User:Lukas9950|Lukas9950]] ([[User talk:Lukas9950|talk]]) 19:30, 13 October 2012 (UTC)

== Download script ==

Hi,

I created a script to automatic download a particular mediawiki version and all extensions I use and prepare tarballs in a directory for easy update.
As I'm not a poweruser, I'd like to have your opinion on my script.

# Is there an easier way to extract infos from git ?
# I haven't found any tag version in extensions, can I know if an extension is link to a newer branch functionalities ?

You can find it in here : https://www.mediawiki.org/wiki/User:Jibec/git-script

Thanks by advance, [[User:Jibec|Jibec]] ([[User talk:Jibec|talk]]) 13:13, 1 November 2012 (UTC)
:Some are a bit pessimistic about it. From #wikimedia-tech:
:2012-11-02 10.47 < TimStarling> 1.19 was the last version with extension branches<br>
:2012-11-02 10.47 < TimStarling> and nobody has adjusted their attitude towards backwards compatibility, so probably there will be no way to get working extensions for release tarballs in future [[User:Nemo_bis|Nemo]] 23:21, 5 November 2012 (UTC)
::Thanks for you answer.
::It's not a good new for any of the individual wiki maintainer.
::Especialy if there is no workaround. Or maybee is there one ?
::Can we imagine to set a list of git tag each extension is compatible with ?
::My script probably is very poor, but do you have any suggest ? [[User:Jibec|Jibec]] ([[User talk:Jibec|talk]]) 00:15, 6 November 2012 (UTC)

== Template removal ==

With reference to [https://www.mediawiki.org/w/index.php?title=Download_from_Git&diff=651052&oldid=650918 this edit], is there reason to believe that [[:Template:Git and Gerrit]] is confusing? Wouldn't downloaders realize that it pertains to developers, much as when we go to download other open source software, we often find some information that is primarily for developers? I think it's important to help devs, especially new devs, find their way around via such navigation templates. [[User:Leucosticte|Leucosticte]] ([[User talk:Leucosticte|talk]]) 19:00, 8 November 2013 (UTC)
:The template doesn't give any hint about it being for devs. It says for instance just "Getting started", which is surely wrong if one is "getting started" with a wiki (often git is the only functioning way to do updates). [[User:Nemo_bis|Nemo]] 23:37, 8 November 2013 (UTC)

== Upgrading using git ==

If I have downloaded version X using git, how do I upgrade the files to version Y using git? Which of these two options?

1. ''git checkout <tag name>'' -- source: https://www.mediawiki.org/wiki/Download_from_Git#Switching_to_a_different_version

Or

2. ''If using Git, export the files into a clean location, and then copy the old customized files into the new location as described on the previous section.'' -- source https://www.mediawiki.org/wiki/Manual:Upgrading#Using_Git

Is option 2 just for the '''first''' time you use git?

Thanks [[User:Jonathan3|Jonathan3]] ([[User talk:Jonathan3|talk]]) 21:56, 25 November 2013 (UTC)

== Trying to update Mediawiki using Git. Have I misunderstood Git? ==

Hi,

I'm looking for a little help please.
My mediawiki installation is located in the following directory: "public_html/w"
I have Git installed on my server and I have managed to clone the git repository to "public_html/w/core" using "git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git". I was then able to switch to the current stable version, 1.22 using "git checkout -b REL1_22 origin/REL1_22".

I was under the impression that I would then be able to use the repository to update my Mediawiki installation (currently 1.21.2) but I can't seem to figure that out. Do I have to manually copy the files from the repository and then run update.php? Have I misunderstood what Git can be used for? How can I do this? I also tried cloning the repository into "public_html/w" by using "git clone https://gerrit.wikimedia.org/r/p/mediawiki/w.git" but it results in an error because the folder isn't empty. 

I would really appreciate any help you can give as I think it will be so much easier for me being able to switch between versions using Git. 

Regards
Craig [[User:Craig Mackay|Craig Mackay]] ([[User talk:Craig Mackay|talk]]) 22:35, 10 December 2013 (UTC)
:Nevermind, I figured it out. I was having issues with file ownership and permissions on my server. Everything is functioning as it should now. [[Special:Contributions/2.121.17.2|2.121.17.2]] 00:48, 12 December 2013 (UTC)

== Say how to remove an extension ==

Say how to remove an extension too. [[User:Jidanni|Jidanni]] ([[User talk:Jidanni|talk]]) 00:33, 7 April 2014 (UTC)
:Just remove extension folder and <code>require_once</code> from <code>LocalSettings.php</code>, that's all. [[User:2nd|2nd]] 10:11, 9 May 2014 (UTC)

== Say how to update a SINGLE extension ==

Say how to update a SINGLE extension too. [[User:Jidanni|Jidanni]] ([[User talk:Jidanni|talk]]) 00:57, 7 April 2014 (UTC)
:Cd to ext
:<syntaxhighlight lang="dos">
cd extensions/abcExtension/
</syntaxhighlight>
:If need watch diff
:<syntaxhighlight lang="dos">
git fetch origin
git diff HEAD origin/master
git merge origin/master
</syntaxhighlight>
:Or immediately apply changes
:<syntaxhighlight lang="dos">
git pull origin master
</syntaxhighlight> [[User:2nd|2nd]] 17:57, 7 May 2014 (UTC)

== Skin installation: do not checkout master branch ==

I've just upgrated to version 1.24 from 1.22. Do do so I needed to install a skin, since it doesn't come with MW. I've spent 3 hours fixing an error in Vector's skin display, because the guide tells you to install the master branch only.

I've now however understand that for the skin also, one should install the REL1_24 branch, using
<code>git checkout -b REL1_24 origin/REL1_24</code>

It seems at this time, the master branch was buggy or incompatible. If you understand the release process better than I do and think I am correct, would you be so kind to amend the documentation? Thanks. [[User:FelixKaiser|FelixKaiser]] ([[User talk:FelixKaiser|talk]]) 14:24, 29 November 2014 (UTC)
:MediaWiki from Git is pretty much unusable these days, with all the dependencies. Do you have strong reasons to use Git instead of the tarball? [[User:Nemo_bis|Nemo]] 07:27, 2 December 2014 (UTC)
:Didn't the [[Download_from_Git#Using_Git_to_download_MediaWiki_skins|Using_Git_to_download_MediaWiki_skins]] part help? Or is it not obvious enough that you are supposed to download the skins this way? (Too late/in the wrong section?) [[User:Frimelle|Frimelle]] ([[User talk:Frimelle|talk]]) 14:50, 23 February 2015 (UTC)
::wasn't obvious to me anyway.  I just spent three hours before figuring out that there were branches for the skins too.  whoops.  I was bold and added to the documentation. [[User:John.james|John.james]] ([[User talk:John.james|talk]]) 03:30, 4 May 2015 (UTC)

== Mention access rights ==

This guide does not talk about necessary file access rights for Mediawiki to run after installation in this way. Installing Mediawiki without these rights will not succeed, which is why I think it should be added. [[User:FelixKaiser|FelixKaiser]] ([[User talk:FelixKaiser|talk]]) 14:32, 29 November 2014 (UTC)

== Download not for development ==

*User sees section 'Download for development'.
*User wants section 'Download not for development'.
*User researches the advice "git clone --depth 1, then e.g., git pull (--depth=1 too?) monthly".
*After several years user finds du -sh showing
 1.5G    mediawiki/
 1.4G    mediawiki/.git
*User does not need history filling up his disks! [[User:Jidanni|Jidanni]] ([[User talk:Jidanni|talk]]) 19:51, 26 March 2015 (UTC)
:great tip to put in --depth=1 - I haven't investigated much, but i do:
:<code> git clone --depth=1 https://gerrit.wikimedia.org/r/p/mediawiki/core.git</code> [[Special:Contributions/80.197.69.174|80.197.69.174]] ([[User talk:80.197.69.174|talk]]) 17:26, 6 December 2015 (UTC)

== Using Git to download MediaWiki skins ==

If you want to download all skins for development, one might be tempted to:
        git clone ssh://purodha@gerrit.wikimedia.org:29418/mediawiki/skins.git
        cd skins
        git review -s
        git submodule update --init --recursive
That creates a set of files but they cannot be used to submit amendments.
If you try:
        cd <someskin>
        git review -s
you get:
        Problems encountered installing commit-msg hook
        /.../<someskin>/.git/hooks/commit-msg: Not a directory
        protocol error: expected control record
and attempts to use:
        git review ...
so as to submit patches yields similar error messages.

Please document a correct working way to solve the problem. [[User:Purodha|Purodha Blissenbach]] ([[User talk:Purodha|talk]]) 21:02, 9 April 2015 (UTC)

== So how do I ... ???? ==

I cloned several extensions into .../extensions. Thereafter I tried to be a real smart ass by trying to switch all of them to the 1.23 branch. I did as instructed "git submodule update --init --recursive" followed by "git submodule foreach 'git checkout -b REL1_23 origin/REL1_23 || :" The I run update.php and get the following message: This version of the CharInsert extension requires MediaWiki 1.25+. That's awesome but does not help me since I want to do 1.23. Any hint appreciated. [[Special:Contributions/91.65.247.81|91.65.247.81]] ([[User talk:91.65.247.81|talk]]) 00:55, 22 November 2015 (UTC)
:Even if I go to /extensions/CharInsert and do "git checkout -b REL1_23 origin/REL1_23" the update.php script tells me This version of the CharInsert extension requires MediaWiki 1.25+??? [[Special:Contributions/91.65.247.81|91.65.247.81]] ([[User talk:91.65.247.81|talk]]) 01:01, 22 November 2015 (UTC)
:I just found out that I messed something with CharInsert while trying to to what is described in my first post. So if I do "git checkout -b REL1_23 origin/REL1_23" in every exension's folder I am cool. So how do I save time and do it for all of them in one go. This will be great. [[Special:Contributions/91.65.247.81|91.65.247.81]] ([[User talk:91.65.247.81|talk]]) 01:19, 22 November 2015 (UTC)
:The internet tells me to do something like "git submodule foreach --recursive git checkout -b REL1_23 origin/REL1_23" This does not work either. Still looking for a solution to not having to do it for say 50 extensions ... or is it that git is just a flawed system. There must be a trick I guess. [[Special:Contributions/91.65.247.81|91.65.247.81]] ([[User talk:91.65.247.81|talk]]) 01:27, 22 November 2015 (UTC)
:Probably this only works if you download the whole lot of extensions and not an isolated set of say 50. I guess git is funny ha ha Let's do the solos :) [[Special:Contributions/91.65.247.81|91.65.247.81]] ([[User talk:91.65.247.81|talk]]) 01:36, 22 November 2015 (UTC)
:It doesn't sound like you used submodules to initially install the extensions, did you? <span style="color:#d30000">☠</span>[[User:MarkAHershberger|MarkAHershberger]]<span style="color:#d30000">☢</span>([[User_talk:MarkAHershberger|talk]])<span style="color:#d30000">☣</span> 16:09, 23 November 2015 (UTC)
:No I did not, but did not realize this in the heat of the action. There should be a note about it. [[Special:Contributions/91.65.247.81|91.65.247.81]] ([[User talk:91.65.247.81|talk]]) 22:57, 24 November 2015 (UTC)
:I just used the exact commands you gave and successfully set up gerrit.  In fact, I did
:<code>    $ cd skins; git submodule foreach git review -s</code>
:and had success.  Well, it did fail on the WPtouch skin, for some reason, but setting the gerrit remote in that directory manually allowed it to continue.
:To set the gerrit remote in that directory:
:<code>    $ cd WPTouch; git remote add gerrit URL</code> <span style="color:#d30000">☠</span>[[User:MarkAHershberger|MarkAHershberger]]<span style="color:#d30000">☢</span>([[User_talk:MarkAHershberger|talk]])<span style="color:#d30000">☣</span> 19:52, 25 November 2015 (UTC)

== Download skins section ==

I was recently installing MediaWiki with someone who did it for the first time. The skins part was what I saw them struggling most with. 

I think that's mainly because:
* It's so late in the manual
* It doesn't mention anywhere before you'll have to install skins (if it's supposed to stay where it is, it should be mentioned before that the step is necessary)
* The section itself links to another tutorial, for beginners it would be nicer to have a quick "How to set up the Vector skin and here is a link to how to work with all the other skins if you know what they do already"
I would like to change it in the way suggested but am open for feedback. Therefore I thought I mention it here and see if there are other/opposing opinions. [[User:Frimelle|Frimelle]] ([[User talk:Frimelle|talk]]) 19:29, 1 November 2016 (UTC)
:The proposed changes sound reasonable to me. Many of our docs are written by people with very deep knowledge of how our software is intended to be used. That perspective often leads to docs that very precisely correct but not necessarily easy to follow. Copy editing always welcome! The worst thing that could possibly happen is a revert. :) [[User:BDavis (WMF)|BDavis (WMF)]] ([[User talk:BDavis (WMF)|talk]]) 20:32, 1 November 2016 (UTC)

== Problem with 'git submodule update' ==
{{Archive top|status=resolved}}

I'm just trying to downloading all extensions, following this sequence:
 git clone https://gerrit.wikimedia.org/r/p/mediawiki/extensions.git
 cd extensions
 git submodule update --init --recursive
The problem is that some extensions asks for authentication. I've made account in https://gerrit.wikimedia.org but it is 'Unauthorized' and result is:
<pre>$ git submodule update --init --recursive
Cloning into 'Notifications'...
Username for 'https://gerrit.wikimedia.org': Spas.Z.Spasov
Password for 'https://Spas.Z.Spasov@gerrit.wikimedia.org':
remote: Unauthorized
fatal: Authentication failed for 'https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Notifications.git/'
fatal: clone of 'https://gerrit.wikimedia.org/r/p/mediawiki/extensions/Notifications.git' into submodule path 'Notifications' failed

(I found that extension '2ColConflict' also make this trouble...)

Could someone help me get through this? Spas.Z.Spasov (talk) 12:11, 1 December 2016 (UTC)

Same problem to me. Notifications asks username and password. Jaider ^msg 19:00, 1 December 2016 (UTC)

@Spas.Z.Spasov I did

cd extensions/

git submodule foreach 'git checkout -b REL1_28 origin/REL1_28 || :'

git submodule update --init --recursive

And now it works. Jaider ^msg 23:45, 20 December 2016 (UTC)

Thank you! I will try it these days. And will report also. Spas.Z.Spasov (talk) 10:58, 22 December 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

What external libraries that MediaWiki requires are no longer in this "core" git repository?

The "Fetch external libraries" section states that "external libraries that MediaWiki requires are no longer in this "core" git repository".

Which libraries are no longer included?

These instructions are given to install these needed libraries "composer install --no-dev". My understanding of composer is that --no-dev tells composer to skip installing packages listed in require-dev. How then would a command that tells composer to skip installing certain packages cause it to install additional required libraries? orestn (talk) 03:38, 3 January 2018 (UTC)

Ah, I hadn't paid attention to the part in the documentation that says "switch to your core directory" before running composer install.

I had been running "composer install" in the project root folder. This folder has a composer.json which requires mediawiki/core.

I see now that there is another composer.json file in the vendor/mediawiki/core folder and that running composer install in this folder brings in additional libraries.

I still don't understand why running composer install at the project root doesn't resolve all dependencies when it installs mediawiki/core. orestn (talk) 04:34, 3 January 2018 (UTC)

> I had been running "composer install" in the project root folder. This folder has a composer.json which requires mediawiki/core.

What is your project root folder? Where did you get this folder from, and why does it have a composer.json that requires "mediawiki/core"?? Legoktm (talk) 06:59, 3 January 2018 (UTC)

Translation: source needs update

Source in en, and under Translations:Download from Git/46/en, Nightlies actually redirects to Hourlies. Please correct the term "Nightlies" to "Hourlies", or is it intentional? Double post to Project:Support desk/Flow/2018/06#h-Please_update_translation_source-2018-06-05T13:19:00.000Z in Project:Support desk. Omotecho (talk) 13:27, 5 June 2018 (UTC)

Why "install-dir" are translatable?

Are those "translations" of commands really work in Git softwares? Liuxinyu970226 (talk) 14:00, 7 June 2018 (UTC)

Keeping an addendum indicating the change from old standards

I suggest there be an addendum created on this page (and others) indicating when a standard has changed -- links, for example. Doing so would allow users to find this page through a search engine when querying the older style links that are used in a plethora of non-updated examples. This would save others from the repeat of my unproductive experience:

I was following this page: https://stackoverflow.com/questions/49267591/how-to-best-add-extensions-when-using-official-docker-image-for-mediawiki in learning how to add some extensions but got tripped up on the old standard of linking to the code repository:

gerrit.wikimedia.org/r/p/mediawiki/extensions

whereas it is now:

gerrit.wikimedia.org/r/mediawiki/extensions

Most older examples accessing the repository incorporate the old standard link which no longer work and do not lead here. Paradox of Thrift (talk) 22:19, 13 January 2021 (UTC)

We can't really fix other people's outdated sites, sadly. There was quite a lot of noise made at the time of the gerrit upgrade two(?) years ago that /r/p/ links won't work any more. The more banners and warnings you put on these pages, the more readers will ignore them entirely, or miss the important bits. Jdforrester (WMF) (talk) 23:36, 14 January 2021 (UTC)

using depth when cloning a tag

I couldn't find anything related here.

I wanted to use git to download the 1.35.1 tag but with --depth=1. I think it is workth mentioning on Download from Git#Download a stable branch that (from what I found on google) this is the command:

git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch 1.35.1 --depth=1 mediawiki

so instead of cloning a actual branch, we can use the tag.

How did I get to this you may ask? Well when first doing:

git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --branch REL1_35 mediawiki --depth=1

and than

git checkout 1.35.1

(as the page suggests) you wont get anywhere, because no tags where downloaded.

Am I missing something? Let me know please. Berot3 (talk) 14:06, 21 January 2021 (UTC)

or is it so that --branch REL1_35 already is on tag 1.35.1? But than why should I checkout 1.35.1? Berot3 (talk) 14:21, 21 January 2021 (UTC)

Try the following:

git clone -b 1.35.1 --single-branch  https://gerrit.wikimedia.org/r/mediawiki/core.git mediawiki

☠MarkAHershberger☢(talk)☣ 15:32, 21 January 2021 (UTC)

Never mind, it looks like using git to specify a single tag as the branch is the quickest and most light-weight checkout.

Checking out the entire repo and then fetching just that tag takes me about half a minute longer and 40mb more space than just checking out a single branch:

time (

git clone https://gerrit.wikimedia.org/r/mediawiki/core.git &&

cd core &&

git checkout 1.35.1

) && du -sh core

...

user 5m11.114s

...

448M core

vs.

time git clone -b 1.35.1 --single-branch \

https://gerrit.wikimedia.org/r/mediawiki/core.git &&

du -sh core

...

user 4m40.874s

...

407M core

But your method is fast and cheap.

time git clone -b 1.35.1 --depth 1 \

https://gerrit.wikimedia.org/r/mediawiki/core.git &&

du -sh core

...

user 0m2.076s

...

174M core ☠MarkAHershberger☢(talk)☣ 15:55, 21 January 2021 (UTC)

Thanks, but I just googled ;)

Did you maybe see my second question? I’m a bit confused, if just clone the branch, am I already on 1.35.1? If so than I could also clone the branch with depth=1. Berot3 (talk) 20:55, 21 January 2021 (UTC)

A branch is not the same as a tag. Commits can be on a branch after the revision tagged 1.35.1. If you want 1.35.1, it is best to directly check it out. ☠MarkAHershberger☢(talk)☣ 22:22, 21 January 2021 (UTC)

so as I thought, on both (-b 1.35.1 and -b REL1_35) I am greeted with the initial setup for 1.35.1.

Sure, as you said, if you really want the exact version from the release-date, use the tag. But I guess when I stay on the branch REL1_35 and there comes version 1.35.2 around, I will probably only have to run git pull --recurse-submodules to get the latest code. Berot3 (talk) 15:06, 28 January 2021 (UTC)

but that is my problem with the page: it suggest using --depth=1 (with -b REL1_35), but when doing so, I can not later git tag -l | sort -V and git checkout 1.35.1.

The text needs to be written like that: If you want clone a tag (1.35.1) AND use --depth=1 you have to clone it directly with -b 1.35.1.

Or am I totally in the wrong here? Berot3 (talk) 15:58, 28 January 2021 (UTC)

Last night I had to pull get branches for a shallow clone, so I ended up looking for the answer.

The answer is that you have to tell git where to get branches from:

git remote set-branches origin '*'

git fetch

After that, you'll be able to check out branches from a repo that you originally created with a shallow clone. ☠MarkAHershberger☢(talk)☣ 15:52, 29 January 2021 (UTC)

well at first I think we are talking about two different problems:

1. Problem: is it better to use branches (REL1_35) or tags (1.35.1). I think we should at first clarify on the article that a: there are two ways to clone the stable branch/tag and b: it is recommended to always clone the current stable tag instead of the branch. Would you agree? So when 1.36 comes along, it would be better to clone --branch 1.36 instead of REL1_36 (i still find it confusing that --branch is used for branches and tags qually. that means you can't have a tag with the same name as a branch, right?)
2. Problem: use of depth It is not clear from the description of the page that you can't use git tag -l | sort -V after you cloned with depth=1! So I would explain it in a way that you either clone without depth and than be able to switch tags or use depth=1. of course (thanks for that) here is your command coming in handy (when cloned with depth=1) git remote set-branches origin '*' git fetch

Did I miss something? :) Berot3 (talk) 12:39, 1 February 2021 (UTC)

i still find it confusing that --branch is used for branches and tags qually. that means you can't have a tag with the same name as a branch, right?

I hadn't thought about it, but I think you're right.

Did I miss something?

I think you've got it. ☠MarkAHershberger☢(talk)☣ 16:30, 1 February 2021 (UTC)

Keeping up to date (with extensions)

So I tried to make update. git pull in the mediawiki-folder worked fine. but than the page says:

The new version of core may require newer versions of extensions and skins, so you must go into each extension and skin directory and update it with a command like git pull --recurse-submodules.

so I went to extensions/ and into any folder and run git pull. I always got this error:

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>

Did I miss something? Berot3 (talk) 17:17, 28 January 2021 (UTC)

Switch to a branch before using "git pull". Shirayuki (talk) 21:16, 28 January 2021 (UTC)

Thanks. But I wonder if this is necessary? I already pulled the core-repo. Shouldn't there be a command like git submodule update --init to also update all the sub-modules? I don't think it makes sense to go into every extension-subfolder/module and switch branch and pull manually.

Maybe git submodule update --recursive --remote ? Berot3 (talk) 14:34, 29 January 2021 (UTC)

When you checkout a submodule (for example, Vector via git submodule update --init skins/Vector), the repository for the submodule is on a specific commit, not a branch. That is the cause of the You are not currently on a branch message.

Release branches for MediaWiki have submodules for all the extensions but the measter branch does not. Which means that, yes, you can use git submodule update --init --recursive on release branches for those extensions included in the release branch, but not on master, as a general rule. (That last submodule command will not change anything if your parent repository is on the same revision as it was when you initially checked out the submodules.)

The exception to this rule for master is if you used git to create submodules for the extensions you install. If you add the Foo extension via git submodule add -f http://example.com/foo.git extensions/Foo, then you can update it later using a git submodule command. If you just want to update the already checked-out branches for any submodules, then the command you're looking for is git submodule foreach git pull. ☠MarkAHershberger☢(talk)☣ 16:05, 29 January 2021 (UTC)

ok, I think I should have clarified that I not intend to be on master. sorry.

I want to clone stable:

1. clone -b 1.35.1 --depth=1
2. git submodule update --init

That means I have also the bundled extensions with stable version.

My question now is: Should I update the bundled extensions from time to time when they release new version (or don't they?)?

Or should I wait for the next stable release of mediawiki where I will clone the new bundled extensions? Berot3 (talk) 13:05, 1 February 2021 (UTC)

ok, I think I should have clarified that I not intend to be on master. sorry.

No, I understood that. What I said stands.

Should I update the bundled extensions from time to time when they release new version (or don't they?)?

If any of the bundled extensions has a back-ported fix, the MediaWiki version will change. Because of the development that most of core MW and the bundled extensions have used, they tend not to back-port anything but security fixes. Announcements for these updates are made on the announcements mailing list.

So, unless you want to spend the time to follow master or the WMF branches, you don't have to worry about upgrading your extensions outside of the MW update cycle. ☠MarkAHershberger☢(talk)☣ 16:27, 1 February 2021 (UTC)

downloading vendor

I have a question regarding /vendor (#Fetch_external_libraries)

I am downloading with

• git clone https://gerrit.wikimedia.org/r/mediawiki/core.git --depth=1 --branch 1.35.1 mediawiki

• git submodule update --init --recursive

When I look under /vendor, I can see that it is not empty. Is it possible that in my case it is not necessary to use composer or download from git once more?

From what I understand I only need composer for additional extensions? Berot3 (talk) 14:31, 1 February 2021 (UTC)

Right, MW's git repo has a vendor submodule. If you just use that git checkout, you don't need to run composer update (unless you want to update one of the dependencies). ☠MarkAHershberger☢(talk)☣ 16:18, 1 February 2021 (UTC)

link to list of skins does not work

new link is https://gerrit.wikimedia.org/r/admin/repos/q/filter:mediawiki%252Fskins QDinar (talk) 06:38, 22 June 2021 (UTC)

Done Shirayuki (talk) 10:41, 22 June 2021 (UTC)

Download_from_Git#MediaWiki_tags_(stable_version) lts and legacy

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Ain't 1.31.15 the legacy and 1.35.3 the lts - exactly the opposite of what's said in the section? 178.148.200.2 (talk) 12:17, 1 July 2021 (UTC)

Fixed. 1.35.3 is both the "LTS" and the "legacy" release. 1.31.15 is the "legacy LTS". Legoktm (talk) 17:28, 1 July 2021 (UTC)

This isn't fixed, it's just differently broken. It now renders as "Currently, these are 1.36.1 (stable), 1.35.3 (LTS) and 1.35.3 (legacy)." Jdforrester (WMF) (talk) 18:01, 1 July 2021 (UTC)

We can "fix" it temporarily by making it:

Currently, these are {{MW stable release number}} (stable), {{MW lts release number}} ([[LTS]]) and {{MW legacy lts release number}} (legacy LTS).

… and then when 1.31 goes EOL changing it to:

Currently, these are {{MW stable release number}} (stable) and {{MW lts release number}} ([[LTS]]).

Sound reasonable? Jdforrester (WMF) (talk) 18:07, 1 July 2021 (UTC)

It does to me. The way it is now is a bit confusing. I guess it's less inaccurate than previously but it makes one (me) wonder why the same versions are mentioned twice. 178.148.200.2 (talk) 23:43, 4 July 2021 (UTC)

Altered. Jdforrester (WMF) (talk) 08:51, 12 July 2021 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Proper way to update

According to Download from Git#Keeping up to date, to do a minor update from, say, MediaWiki 1.39.1 to 1.39.3, I should do the following:

git pull
composer update --no-dev
php maintenance/update.php

This I do, and all goes well. However, after a successful update, I'd expect that running git status should yield an empty report (no unstaged changes, no untracked files), but it doesn't. Instead, I see all bundled extensions listed as unstaged changes, and all non-bundled extensions listed as untracked.

The first list I usually resolve by running:

git submodule update --init --recursive

Should this be added to Download from Git#Keeping up to date?

And what about the non-bundled extensions that appear listed as untracked? Is this expected? Shouldn't the extensions directory be included in .gitignore or something? What's the proper way to do a minor update? Sophivorus (talk) 12:48, 25 April 2023 (UTC)

It depends a little bit on how you're using git. If you are following tags, you would need to change to the 1.39.3 tag first. If you are following a release branch, then git pull would work.

I would recommend git pull --recurse-submodules if using a release branch so it automatically updates submodules.

Extra extensions you added being untracked is to be expected. Perhaps extensions other then bundled ones should be added to .gitignore, but that is not currently done at this time. Bawolff (talk) 07:41, 28 November 2023 (UTC)

Best practice for maintaining a local fork?

I manage a MediaWiki site that is basically the REL1_39 branch plus LocalSettings.php and a few extensions I wrote myself. What is the best practice for maintaining this kind of set up with Git, so I can easily update the core MediaWiki software without disturbing my custom files?

I thought maybe I could create a local Git branch named mine that's based on origin/REL1_39 and add my files. I would never commit this branch to Gerrit -- it just stays on my local host. Then, when MediaWiki is updated to (say) 1.40, I'd just git merge origin/REL1_40 into my mine branch. But when I tried this locally, I got many merge conflicts.

Or, I could maintain my private files (LocalSettings.php etc.) in a separate local Git repository, and then at deployment time, combine the MediaWiki core files and my repository on our production server. But writing scripts to deploy files from 2 separate Git repositories feels a little hacky.

Is there a better way? Thank you very much. Maiden taiwan (talk) 00:07, 29 March 2024 (UTC)

If you got merge conflicts when doing git merge origin/REL1_40, it means that your own modifications touched parts of the code that changed between 1.39 and 1.40. I don’t think there’s an automated way to resolve those conflicts, no matter if you use a different branch, a different repo or something else – programs can’t read your mind to figure out what you wanted to do. A branch in the same repo is IMO the best solution exactly because of the conflicts: the conflicts highlight what cannot be merged automatically (and do so well before deployment, so the manual merging doesn’t cause downtime).

However, if you touched only LocalSettings.php and added extensions, there should be no conflicts: LocalSettings.php is ignored in Git, and extensions have their own directories. (Unless you happened to have chosen names that haven’t been in 1.39 but are in 1.40: in that case, simply rename your own extension.) So the question is: what else did you modify in MediaWiki core, and could those modifications either be submitted to Gerrit so that you don’t have conflicts in the future, or be reverted because the official version of MediaWiki now provides you what you need? Tacsipacsi (talk) 09:47, 29 March 2024 (UTC)

Thanks @Tacsipacsi! I actually didn't modify anything in MediaWiki core. Here's what happens with a simple merge of the kind I described.

$ git clone https://gerrit.wikimedia.org/r/mediawiki/core.git

$ cd core

$ git switch REL1_39

$ git switch -c foobar

$ git merge origin/REL1_40

This give me tons of merge conflicts.

CONFLICT (add/add): Merge conflict in .gitmodules

CONFLICT (content): Merge conflict in autoload.php

CONFLICT (content): Merge conflict in composer.json

etc.

What am I doing wrong? Maiden taiwan (talk) 15:57, 29 March 2024 (UTC)

I see. I didn’t realize what you effectively try to do is merging 1.40.3 into 1.39.7. Since they have independent history since 1.39 got branched, conflicts are actually not surprising. If you indeed don’t touch anything except for LocalSettings.php and your custom extensions, maybe the best solution is not to maintain your own branch of MediaWiki:

• Maintain extensions separately, one repo per extension. This is also how extensions are maintained on Gerrit.
• Maintain LocalSettings.php in yet another repo.
• Create a deployment script that deploys the extensions (this could go in the same repo as LocalSettings.php). Two possibilities:
  • Simply cd extensions && git clone ../../custom-extensions/extension-name
  • git submodule add ../../custom-extensions/extension-name extensions/extension-name && git submodule update (this helps with later updates, but makes the working tree dirty)
• Make sure LocalSettings.php is kept up to date, for example by copying it with the above script, or by symlinking it.

P.S. Please note that I’m just one person. This is how I’d do it, but it may not be the best solution. Tacsipacsi (talk) 17:39, 30 March 2024 (UTC)

Thank you @Tacsipacsi. I'll give that a try. Maiden taiwan (talk) 18:46, 31 March 2024 (UTC)