A want to march a staging site currently in release 3.5 along the Moodle "master" to jump to 3.9 "stable" as soon as it is available.
The current site has been downloaded with
$ git clone git://git.moodle.org/moodle.git
$ cd moodle
$ git branch --track MOODLE_35_STABLE origin/MOODLE_35_STABLE
$ git checkout MOODLE_35_STABLE
and then kept current with
$ git pull
In that I have $release = '3.5.11+ Build...' and $branch = '35'. When I clone Moodle now I get $release = '3.9dev+ Build...' and $branch = '39'.
What are the Git commands to march the current 3.5 site to "master" now? And what is needed to take it to 3.9 Stable, once it is released?
'When I clone Moodle now I get $release = '3.9dev+ Build...' and $branch = '39'.'
How are you 'cloning'?
To upgrade from 3.5 -> 3.9 when released:
cd moodlecode
php admin/cli/maintenance.php --enable;
git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE; git checkout MOODLE_39_STABLE; php admin/cli/upgrade.php --non-interactive'SoS', Ken
Hi Ken
>> When I clone Moodle now I get $release = '3.9dev+ Build...' and $branch = '39'.
> How are you 'cloning'?
$ git clone git://git.moodle.org/moodle.git
> To upgrade from 3.5 -> 3.9 when released:
> cd moodlecode
> php admin/cli/maintenance.php --enable;
> git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE;
> git checkout MOODLE_39_STABLE;
> php admin/cli/upgrade.php --non-interactive
Thanks! That is the answer to my second question, "And what is needed to take it to 3.9 Stable, once it is released? " - provided that the answer to the first question hasn't tainted the repo. The first question was, 'What are the Git commands to march the current 3.5 site to "master" now?'. ;)
What I am trying to do is a simple thing from a users perspective. I'll try to explain it from a different angle:
1. The prod. Moodle is running release 3.5
2. I took a copy to a staging server. It runs in the new server (under a different domain name, of course).
3. I want to upgrade this staging site straight to Moodle's "master", the latest code in the Git repo (which is the 3.9dev+ I mentioned).
4. Will keep this site in sync with the "master", will be 'git pull'.
5. Once 3.9 is released, I want move ahead on the same instance, upgrade if you want.
I am looking for the Git commands for the steps 4 and 5.
>> When I clone Moodle now I get $release = '3.9dev+ Build...' and $branch = '39'.
> How are you 'cloning'?
$ git clone git://git.moodle.org/moodle.git
> To upgrade from 3.5 -> 3.9 when released:
> cd moodlecode
> php admin/cli/maintenance.php --enable;
> git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE;
> git checkout MOODLE_39_STABLE;
> php admin/cli/upgrade.php --non-interactive
Thanks! That is the answer to my second question, "And what is needed to take it to 3.9 Stable, once it is released? " - provided that the answer to the first question hasn't tainted the repo. The first question was, 'What are the Git commands to march the current 3.5 site to "master" now?'. ;)
What I am trying to do is a simple thing from a users perspective. I'll try to explain it from a different angle:
1. The prod. Moodle is running release 3.5
2. I took a copy to a staging server. It runs in the new server (under a different domain name, of course).
3. I want to upgrade this staging site straight to Moodle's "master", the latest code in the Git repo (which is the 3.9dev+ I mentioned).
4. Will keep this site in sync with the "master", will be 'git pull'.
5. Once 3.9 is released, I want move ahead on the same instance, upgrade if you want.
I am looking for the Git commands for the steps 4 and 5.
Step 3. According to https://stackoverflow.com/questions/1628088/reset-local-repository-branch-to-be-just-like-remote-repository-head the answer is:
git fetch origin
git reset --hard origin/master
Step 4.
git pull
Step 5. After 3.9 stable is released the usual:
git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE;
git checkout MOODLE_39_STABLE;
I am testing - and open for comments, corrections.
git fetch origin
git reset --hard origin/master
Step 4.
git pull
Step 5. After 3.9 stable is released the usual:
git branch --track MOODLE_39_STABLE origin/MOODLE_39_STABLE;
git checkout MOODLE_39_STABLE;
I am testing - and open for comments, corrections.
That looks right.
git fetch origin
git reset --hard origin/master
One way to know for sure ... do it!
'SoS', Ken
Yep, 'git fetch origin; git reset --hard origin/master' is a strong Mantra, brings you to the present. With that I've fast forwarded my 3.5 site to 3.9dev+ 20200512 as of today. Some private adjustments from the past barked, but were expected.
About Moodle and RC: No, there are none. The 3.9dev+ just marches towards the 3.9 Stable branch.
Hint to the community: This solution shows how to do some informal testing of the coming release, the much awaited LLTS (Long Long Term Support) release.
About Moodle and RC: No, there are none. The 3.9dev+ just marches towards the 3.9 Stable branch.
True. They are not there right now. In the past, I have seen releases with RC1's, 2's and 3's ... still 'stable' but RC's non the less.
As I understand it, official release of 3.9.0 has been 'pushed back' some and so you might see ... if you check every day and at the 'right' time (stars/moons aligned just right) ... RC's.
Above just my past experience. Things change, however!
'SoS', Ken
There are no Moodle 3.9 RC yet. As illustrated at https://docs.moodle.org/dev/Moodle_versions, the release candidate versions are the ones between the beta and the actual release. Moodle 3.9 is still waiting for its beta release.
Hi David
Thanks for the correction and the link! https://docs.moodle.org/dev/Moodle_versions#Source_code_maturity_levels explains the RCs. Technically they are Git tags, right, as opposed to 3.9dev which is the "head"?
Hi Visvanath,
I wouldn't recommend to use "git reset --hard". It is not a safe way.
- All changes you may have in your current branch will be lost forever.
- If you have any additional files, they will remain despite the "git reset --hard" command. This can cause problems with future updates and so on.
I'd rather recommend a safer way.
- commit all your changes in your current branch. With that you can easily go back to this point.
git add .
git commit -m "Last stage before switching to master" - Now that you have a clean branch you can just check out the current master branch.
git fetch origin
git checkout master - Until the MOODLE_39_STABLE branch appears you just do a "git pull" to update your branch.
- If the Moodle 3.9 is released you just do the same as before with the master branch.
Best regards
Andreas
Andreas
Hi Andreas
It is exactly as you said. My method forced me to abandon the local changes. In that test scenario it was no big deal. But for the real case I would like to take some changes with me. Yes, 'git fetch origin; git checkout master' allows me that - once the repo is clean (freshly committed). Problem SOLVED.
Interesting detail: Just after 'git checkout master' the version.php showed something rel. 36.. (I've started with a 3.5.x). Only 'git pull' brought the 39dev. Just curious.
Hi Visvanath,
the command to checkout the master that I showed you is a shortcut for further steps that Git automatically does for you.
git checkout <branch>
- It checks whether or not the branch already exists in the local area of your repository
- If the branch is already there, git just does a checkout for this branch and nothing more.
- If the branch is not there git looks in the remote area and checks whether or not the branch exists.
- If the branch exists in the remote area, git does a "git checkout -b <branch> <remote>/<branch>" and creates a reference between the new branch and the remote.
- If there are two or more remotes with the wanted branch, then git can't decide which one it should use and it prints an error. In this case you have to do the full checkout command (see nr. 4) by your self.
In your case the master branch was already there. So the simple command "git checkout master" did only checkout the local master and not the master from the remote. If this old master branch is part of the history of the remote master you can easily do a git pull to get the last version. That's what you did.
Best regards
Andreas
Andreas
From what I re-call, as 3.9dev+ gets release candidates (rc branches), git pull will acquire. Unless I've vol for QA testing I would want 'stable's even if RC releases. Soooo ... ?
Maybe Howard and correct me.
'SoS', Ken