[GRASS-dev] Renaming master branch to main branch

GRASS GIS GRASS GIS developer
1

Dear all,

I will rename our default branch currently called master to main in the following days. We already discussed it here and there, but the rename should be relatively smooth. Much simpler than the addons repo reorganization. Users not compiling code themselves should not be affected. Contributors will be, but GitHub warns you about the rename when you come to the repo web page. Those compiling from source may need to make changes.

The update of a local clone can be done with instructions similar to the following (I will post them again once I confirm it is the best fit):

git branch -m master main
git fetch upstream
git branch -u upstream/main main
git remote set-head upstream -a

Additionally, to get rid of upstream/master, do:

git fetch --prune

You don’t need to update your fork unless you want to.

The changes needed in the repo are already in a PR (feel free to review):

https://github.com/OSGeo/grass/pull/1806

Those compiling from source code obtained from Git will need to make changes when they explicitly specify the branch. A simple git clone takes the default branch which will continue to work. However, if you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change “master” to “main”.

Let me know if you have any questions or concerns.

Best,
Vaclav

2

Here are some screen captures for these same steps, that I created back in January for the MapServer community: https://github.com/MapServer/MapServer/wiki/Renamed-Default-Branch

-jeff

--
Jeff McKenna
GatewayGeo: Developers of MS4W, MapServer Consulting and Training
co-founder of FOSS4G
http://gatewaygeo.com/

On 2021-08-18 11:41 p.m., Vaclav Petras wrote:

Dear all,

I will rename our default branch currently called master to main in the following days. We already discussed it here and there, but the rename should be relatively smooth. Much simpler than the addons repo reorganization. Users not compiling code themselves should not be affected. Contributors will be, but GitHub warns you about the rename when you come to the repo web page. Those compiling from source may need to make changes.

The update of a local clone can be done with instructions similar to the following (I will post them again once I confirm it is the best fit):

git branch -m master main
git fetch upstream
git branch -u upstream/main main
git remote set-head upstream -a

Additionally, to get rid of upstream/master, do:

git fetch --prune

You don't need to update your fork unless you want to.

The changes needed in the repo are already in a PR (feel free to review):

https://github.com/OSGeo/grass/pull/1806

Those compiling from source code obtained from Git will need to make changes when they explicitly specify the branch. A simple `git clone` takes the default branch which will continue to work. However, if you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change "master" to "main".

Let me know if you have any questions or concerns.

Best,
Vaclav

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

3

Dear all,

The master branch was renamed to main. Please update your local repositories and workflows accordingly.

1. Local repo update and branch rename

If you are contributing code or compiling source code from Git, you need to modify your local repository as well. Go to your fork’s website on GitHub. It will warn you about the rename in the OSGeo repo. Go to settings and to the rename. Go to the main page of your fork again. Now it will warn you about the rename in your repo (your fork). It will give you instructions on renaming the local branch and making it point to the renamed branch. (The assumption is that your fork repo is the remote named origin.)

Additionally, there still will be upstream/master and you can remove it using (assuming upstream remote is the OSGeo repo. You can remove upstream/master and update info about the default branch using:

git fetch upstream --prune
git remote set-head upstream -a

Alternatively, if you are not keeping your fork’s master/main branch up to date, you can follow instructions from my initial email which allow you to skip the fork part resulting in a slightly different local setup.

2. Updating your contributing steps

To update your local main branch (base branch) and to rebase or merge with the latest source code, use upstream/main instead of upstream/master.

3. Updating workflows using source code from Git

If you have a workflow which is using the source code obtained from Git , you will need to update it if you explicitly specify the branch name. If you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change “master” to “main”. If you use only a simple git clone, no changes are needed because git clone takes the default branch which will continue to work.

4. Other issues

The base branch for PRs was changed automatically. The PRs updating most of the source code for core and addons were merged. Some CI-related changes will still be needed for core. Additionally, I assume the workflows outside of the source code will be updated as part of the updates to addons repo structure and changes for the release branch for 8.0. Help in this area is welcome.

https://github.com/OSGeo/grass/pull/1806
https://github.com/OSGeo/grass-addons/pull/598

Let me know if you face any questions.

Best,
Vaclav

On Wed, Aug 18, 2021 at 10:41 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

Dear all,

I will rename our default branch currently called master to main in the following days. We already discussed it here and there, but the rename should be relatively smooth. Much simpler than the addons repo reorganization. Users not compiling code themselves should not be affected. Contributors will be, but GitHub warns you about the rename when you come to the repo web page. Those compiling from source may need to make changes.

The update of a local clone can be done with instructions similar to the following (I will post them again once I confirm it is the best fit):

git branch -m master main
git fetch upstream
git branch -u upstream/main main
git remote set-head upstream -a

Additionally, to get rid of upstream/master, do:

git fetch --prune

You don’t need to update your fork unless you want to.

The changes needed in the repo are already in a PR (feel free to review):

https://github.com/OSGeo/grass/pull/1806

Those compiling from source code obtained from Git will need to make changes when they explicitly specify the branch. A simple git clone takes the default branch which will continue to work. However, if you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change “master” to “main”.

Let me know if you have any questions or concerns.

Best,
Vaclav

4

Thank you Vaclav.

Will the same name-update happen for the addons?

Nikos

5

Well, since addon repo structure changed and master is no longer used as base branch, but grass7, and eventually it will be grass8, the name change does not seem very relevant or urgent there, no?

Not strong opinion though

Vero

El mié, 25 ago 2021 a las 21:21, Nikos Alexandris (<nik@nikosalexandris.net>) escribió:

Thank you Vaclav.

Will the same name-update happen for the addons?

Nikos

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

6

On Wed, Aug 25, 2021 at 3:32 PM Veronica Andreo <veroandreo@gmail.com> wrote:

Well, since addon repo structure changed and master is no longer used as base branch, but grass7, and eventually it will be grass8, the name change does not seem very relevant or urgent there, no?

That is correct. A much larger change happened, or rather, is happening for addons.

https://github.com/OSGeo/grass-addons/issues/528

The master branch was kept in the repo for backwards compatibility, so that old g.extension version can install from it, but now it seems rather useless since old version of g.extension wrongly assumes that main or master translate to the default branch, so they can’t fetch addons from branch called master anyway. (master is translated to trunk in the GitHub Subversion interface which is used to fetch the source code, but trunk points to default which is now the new grass7 branch which has the new structure which the old g.extension can’t handle - well, at least as far as I understand)

7

Probably a silly question:

I’m having problems with rebasing my local feature branches for PRs, e.g. for https://github.com/OSGeo/grass/pull/1786
My local main branch is up to date with the official main branch. In my case the grass repo is the remote named origin, my fork is the remote named metzm

$ git checkout raster_tempdir
$ git rebase main

Successfully rebased and updated refs/heads/raster_tempdir.

$ git status
On branch raster_tempdir
Your branch and ‘metzm/raster_tempdir’ have diverged,
and have 48 and 7 different commits each, respectively.
(use “git pull” to merge the remote branch into yours)

$ git push metzm raster_tempdir
! [rejected] raster_tempdir → raster_tempdir (non-fast-forward)
error: failed to push some refs to ‘github.com:metzm/grass.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

Any hints on how to proceed from here without messing up the history of my feature branch? Thanks!

Markus M

On Sun, Aug 22, 2021 at 9:26 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

Dear all,

The master branch was renamed to main. Please update your local repositories and workflows accordingly.

1. Local repo update and branch rename

If you are contributing code or compiling source code from Git, you need to modify your local repository as well. Go to your fork’s website on GitHub. It will warn you about the rename in the OSGeo repo. Go to settings and to the rename. Go to the main page of your fork again. Now it will warn you about the rename in your repo (your fork). It will give you instructions on renaming the local branch and making it point to the renamed branch. (The assumption is that your fork repo is the remote named origin.)

Additionally, there still will be upstream/master and you can remove it using (assuming upstream remote is the OSGeo repo. You can remove upstream/master and update info about the default branch using:

git fetch upstream --prune
git remote set-head upstream -a

Alternatively, if you are not keeping your fork’s master/main branch up to date, you can follow instructions from my initial email which allow you to skip the fork part resulting in a slightly different local setup.

2. Updating your contributing steps

To update your local main branch (base branch) and to rebase or merge with the latest source code, use upstream/main instead of upstream/master.

3. Updating workflows using source code from Git

If you have a workflow which is using the source code obtained from Git , you will need to update it if you explicitly specify the branch name. If you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change “master” to “main”. If you use only a simple git clone, no changes are needed because git clone takes the default branch which will continue to work.

4. Other issues

The base branch for PRs was changed automatically. The PRs updating most of the source code for core and addons were merged. Some CI-related changes will still be needed for core. Additionally, I assume the workflows outside of the source code will be updated as part of the updates to addons repo structure and changes for the release branch for 8.0. Help in this area is welcome.

https://github.com/OSGeo/grass/pull/1806
https://github.com/OSGeo/grass-addons/pull/598

Let me know if you face any questions.

Best,
Vaclav

On Wed, Aug 18, 2021 at 10:41 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

Dear all,

I will rename our default branch currently called master to main in the following days. We already discussed it here and there, but the rename should be relatively smooth. Much simpler than the addons repo reorganization. Users not compiling code themselves should not be affected. Contributors will be, but GitHub warns you about the rename when you come to the repo web page. Those compiling from source may need to make changes.

The update of a local clone can be done with instructions similar to the following (I will post them again once I confirm it is the best fit):

git branch -m master main
git fetch upstream
git branch -u upstream/main main
git remote set-head upstream -a

Additionally, to get rid of upstream/master, do:

git fetch --prune

You don’t need to update your fork unless you want to.

The changes needed in the repo are already in a PR (feel free to review):

https://github.com/OSGeo/grass/pull/1806

Those compiling from source code obtained from Git will need to make changes when they explicitly specify the branch. A simple git clone takes the default branch which will continue to work. However, if you do --branch, checkout, or switch, and at the same time using the master branch, you will need to change “master” to “main”.

Let me know if you have any questions or concerns.

Best,
Vaclav

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

8

On Fri, Sep 10, 2021 at 1:16 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

…

$ git checkout raster_tempdir
$ git rebase main

Successfully rebased and updated refs/heads/raster_tempdir.

$ git status
On branch raster_tempdir
Your branch and ‘metzm/raster_tempdir’ have diverged,
and have 48 and 7 different commits each, respectively.
(use “git pull” to merge the remote branch into yours)

$ git push metzm raster_tempdir
! [rejected] raster_tempdir → raster_tempdir (non-fast-forward)
error: failed to push some refs to ‘github.com:metzm/grass.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

This is how it is supposed to behave when you do git rebase. Rebasing re-applies the changes you made in raster_tempdir one by one on top of your local main. This creates different commits in the sense that the commit hashes are different. This causes the “have diverged” part. 48 on the local raster_tmpdir is your 7 commits plus 41 commits which happened in the main branch since you created raster_tempdir. 7 commits on metzm/raster_tempdir is the original commits you made which have the original, different hash, so Git considers them to be different.

Force push with git push -f metzm raster_tempdir is appropriate here. You will replace whatever is in the remote branch by your newly updated (rebased) local branch content.

We are currently merging all PRs using the “Squash and merge” feature, this reduces the commit which will go to the main branch to only the actual changes taking care of the merge commits. So, you can use git merge or git rebase on your branches.

I still prefer rebase most of the time because it is easier to review commits in the PR (since there are no merge commits). Some people also use rebase to reduce the commits on a branch to one, but I think that’s usually not helpful for review. However, merge does not require the strange force pushing and it works better in case of conflicts because you are simply merging the latest state, not each commit on your branch which is the case with rebase.

As far as I can tell, the master-main rename should not have any influence on this. And yes, the message from git push is not applicable here.

9

On Fri, Sep 10, 2021 at 7:51 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Sep 10, 2021 at 1:16 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

…
$ git checkout raster_tempdir
$ git rebase main

Successfully rebased and updated refs/heads/raster_tempdir.

$ git status
On branch raster_tempdir
Your branch and ‘metzm/raster_tempdir’ have diverged,
and have 48 and 7 different commits each, respectively.
(use “git pull” to merge the remote branch into yours)

$ git push metzm raster_tempdir
! [rejected] raster_tempdir → raster_tempdir (non-fast-forward)
error: failed to push some refs to ‘github.com:metzm/grass.git’
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: ‘git pull …’) before pushing again.
hint: See the ‘Note about fast-forwards’ in ‘git push --help’ for details.

This is how it is supposed to behave when you do git rebase. Rebasing re-applies the changes you made in raster_tempdir one by one on top of your local main. This creates different commits in the sense that the commit hashes are different. This causes the “have diverged” part. 48 on the local raster_tmpdir is your 7 commits plus 41 commits which happened in the main branch since you created raster_tempdir. 7 commits on metzm/raster_tempdir is the original commits you made which have the original, different hash, so Git considers them to be different.

Force push with git push -f metzm raster_tempdir is appropriate here. You will replace whatever is in the remote branch by your newly updated (rebased) local branch content.

A force push helped, thanks! The commit history of the PR has not been messed up, only the relevant commits are shown.

The reason for the rebase was that some tests were failing, apparently because of a combination of renaming master to main and changes to GHA, and a PR can only be squashed and merged if all tests are passed.

Thanks for the fast response!

Markus M

10

On Fri, Sep 10, 2021 at 2:30 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

The commit history of the PR has not been messed up, only the relevant commits are shown.

Right, right, Git or GitHub recognizes that thoise 41 are already on main.

The reason for the rebase was that some tests were failing, apparently because of a combination of renaming master to main and changes to GHA, and a PR can only be squashed and merged if all tests are passed.

Ah, that makes sense. You need to update in one way or another in this case.

11

On Fri, Sep 10, 2021 at 8:46 PM Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Fri, Sep 10, 2021 at 2:30 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

The reason for the rebase was that some tests were failing, apparently because of a combination of renaming master to main and changes to GHA, and a PR can only be squashed and merged if all tests are passed.

Ah, that makes sense. You need to update in one way or another in this case.

After git rebase main + git push -f ..., all the previously timed-out tests for the affected PRs are passed, great!

Markus M

12

On Fri, Sep 10, 2021 at 4:36 PM Markus Metz <markus.metz.giswork@gmail.com> wrote:

…all the previously timed-out tests for the affected PRs are passed…

As for the timed-out tests - those which are running actual test suites and time out after 6 hours - that’s actually still an issue. It just usually does not happen. It is not clear to me what the cause is. You can see it stuck at different tests, usually (always?) temporal, but that’s also because there are just a lot of temporal ones. I enabled the test result (artifact) download even for that case, but I didn’t see anything useful there either. However, the fact that the artifact preparation step works suggests that the GitHub VM itself is not stuck and it is really something with our code or tests.