Talk:Download from Git

Jump to navigation Jump to search

About this board

link to list of skins does not work

2
Qdinar (talkcontribs)
Shirayuki (talkcontribs)

Yes Done

Reply to "link to list of skins does not work"

using depth when cloning a tag

11
Berot3 (talkcontribs)

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 (talkcontribs)

or is it so that --branch REL1_35 already is on tag 1.35.1? But than why should I checkout 1.35.1?

MarkAHershberger (talkcontribs)

Try the following:

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

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
Berot3 (talkcontribs)

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.

MarkAHershberger (talkcontribs)

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.

Berot3 (talkcontribs)

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 (talkcontribs)

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?

MarkAHershberger (talkcontribs)

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.

Berot3 (talkcontribs)

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? :)

MarkAHershberger (talkcontribs)
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.
Reply to "using depth when cloning a tag"

Keeping up to date (with extensions)

6
Berot3 (talkcontribs)

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?

Shirayuki (talkcontribs)
Berot3 (talkcontribs)

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 ?

MarkAHershberger (talkcontribs)

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.

Berot3 (talkcontribs)

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?

MarkAHershberger (talkcontribs)
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.

Reply to "Keeping up to date (with extensions)"
Berot3 (talkcontribs)

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?

MarkAHershberger (talkcontribs)

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).

Reply to "downloading vendor"

Keeping an addendum indicating the change from old standards

2
Paradox of Thrift (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

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.

Reply to "Keeping an addendum indicating the change from old standards"

Problem with 'git submodule update'

4
Spas.Z.Spasov (talkcontribs)

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:

$ 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?

Jaideraf (talkcontribs)

Same problem to me. Notifications asks username and password.

Jaideraf (talkcontribs)

@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.

Spas.Z.Spasov (talkcontribs)

Thank you! I will try it these days. And will report also.

Why "install-dir" are translatable?

1
Liuxinyu970226 (talkcontribs)

Are those "translations" of commands really work in Git softwares?

Reply to "Why "install-dir" are translatable?"

Translation: source needs update

1
Omotecho (talkcontribs)
Reply to "Translation: source needs update"

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

3
Orestn (talkcontribs)

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 (talkcontribs)

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.

Legoktm (talkcontribs)

> 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"??

Reply to "What external libraries that MediaWiki requires are no longer in this "core" git repository?"
91.65.247.81 (talkcontribs)

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.

91.65.247.81 (talkcontribs)

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+???

91.65.247.81 (talkcontribs)

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.

91.65.247.81 (talkcontribs)

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.

91.65.247.81 (talkcontribs)

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 :)

MarkAHershberger (talkcontribs)

It doesn't sound like you used submodules to initially install the extensions, did you?

91.65.247.81 (talkcontribs)

No I did not, but did not realize this in the heat of the action. There should be a note about it.

MarkAHershberger (talkcontribs)

I just used the exact commands you gave and successfully set up gerrit. In fact, I did

   $ cd skins; git submodule foreach git review -s

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:

   $ cd WPTouch; git remote add gerrit URL
Reply to "So how do I ... ????"