Re: FYI Renaming default branch from "master" to "main"

In-Reply-To=<e5d8cb0e8110f79c8fe0cfb9a508c4b6%40posteo.de> Hello, renaming is done. Be aware to update your local repositories or re-clone them; also your forks on GitHub. Beside the new "main" branch I created the "dev" branch. In the past I used the name "develop" but found out it is unusual and a bit to long. I think "dev" is easier (for some of us). :D Hope this is OK. I also updated the target branch in all existing and open Pull Requests. I created a new Pull Request updating version numbers, changelog and mention the "dev" branch in the README.md. @Jürgen: I know you work on some FAQ and maybe README. Maybe this will cause a merge conflict. But some md-files are a secure learning case I think. ;) I assume your upcoming docu changes should go into "main" too? I suggest to merging it into "dev" and then picking the changes form there into "master". I would do that via "git checkout my.file dev". I never used git's cherry pick before. This is one exception of the only-release-commits-in-main because "main" do produce the landing page via its README.md. Kind Christian

On Mon, 2023-01-16 at 09:34 +0000, c.buhtz@posteo.jp wrote:
Beside the new "main" branch I created the "dev" branch.
Thanks lot for this huge repo change! I could successfully migrate my cloned repo.
I would only send a PR for dev only since our intention was to keep the dev-doc in sync with the code.
Agreed! Changes of the README.md landing page (incl. related) files may always go to "dev" + optionally immediately also to "main" if it is not only related to "dev" code but also for the current release.

On Mon, 2023-01-16 at 09:34 +0000, c.buhtz@posteo.jp wrote:
Cherry-picking a commit or even checking out single file to merge/commit it into another branch is IMHO more complex than commiting to "main" and forward-integrate the commit via merging "main" into "dev". If we stick to PRs for README.md changes in "main" we also have a "2nd line of defense" against mistakes by using 4++ eyes... Any comments or other proposals?

Moin Am 23.01.2023 11:46 schrieb BiT dev:
I agree. If we have to do this the commit wasn't small (atomar?) enough. ;) But sometimes a commit changed to many things and you don't want to have all of that changes in your "main".
commiting to "main" and forward-integrate the commit via merging "main" into "dev".
It is also a way. There are many ways with git. Makes me headache often. ;) I had in mind that most of the time "main" and "dev" are to far away form each other. And merge one into the other would cause a lot of trouble and merge conflicts. Imagine in one year when main is just "1.3.3" but in dev we fixed and added a lot of things (~ 100 commits) then we add new information to the README.md... In that case there may be an easier way. But for myself as a git-unprofessional I would simple checkout the README.md from dev in main.
If we stick to PRs for README.md changes in "main" we also have a "2nd line of defense"
Yeah! For me it is one of the biggest advantages: I can't destroy that much.
Any comments or other proposals?
I'm fine with stickin to PRs and then see how we solve other upcomming "problems" with git and branches.

I'm fine with stickin to PRs and then see how we solve other upcomming "problems" with git and branches.
Yes, in the end only the correct result counts, not the way. BTW: I just realized that changing the README.md landing page via a "PR branch" is like the hotfix branch workflow which is also merged into master and dev (but not master into dev): https://www.gitkraken.com/wp-content/uploads/2021/06/gitflow-diagram-768x973... This looks even less risky (even though I don't know if a Github PR can be merged into two target branches in parallel or requires another branch)...

On Mon, 2023-01-16 at 09:34 +0000, c.buhtz@posteo.jp wrote:
Beside the new "main" branch I created the "dev" branch.
Thanks lot for this huge repo change! I could successfully migrate my cloned repo.
I would only send a PR for dev only since our intention was to keep the dev-doc in sync with the code.
Agreed! Changes of the README.md landing page (incl. related) files may always go to "dev" + optionally immediately also to "main" if it is not only related to "dev" code but also for the current release.

On Mon, 2023-01-16 at 09:34 +0000, c.buhtz@posteo.jp wrote:
Cherry-picking a commit or even checking out single file to merge/commit it into another branch is IMHO more complex than commiting to "main" and forward-integrate the commit via merging "main" into "dev". If we stick to PRs for README.md changes in "main" we also have a "2nd line of defense" against mistakes by using 4++ eyes... Any comments or other proposals?

Moin Am 23.01.2023 11:46 schrieb BiT dev:
I agree. If we have to do this the commit wasn't small (atomar?) enough. ;) But sometimes a commit changed to many things and you don't want to have all of that changes in your "main".
commiting to "main" and forward-integrate the commit via merging "main" into "dev".
It is also a way. There are many ways with git. Makes me headache often. ;) I had in mind that most of the time "main" and "dev" are to far away form each other. And merge one into the other would cause a lot of trouble and merge conflicts. Imagine in one year when main is just "1.3.3" but in dev we fixed and added a lot of things (~ 100 commits) then we add new information to the README.md... In that case there may be an easier way. But for myself as a git-unprofessional I would simple checkout the README.md from dev in main.
If we stick to PRs for README.md changes in "main" we also have a "2nd line of defense"
Yeah! For me it is one of the biggest advantages: I can't destroy that much.
Any comments or other proposals?
I'm fine with stickin to PRs and then see how we solve other upcomming "problems" with git and branches.

I'm fine with stickin to PRs and then see how we solve other upcomming "problems" with git and branches.
Yes, in the end only the correct result counts, not the way. BTW: I just realized that changing the README.md landing page via a "PR branch" is like the hotfix branch workflow which is also merged into master and dev (but not master into dev): https://www.gitkraken.com/wp-content/uploads/2021/06/gitflow-diagram-768x973... This looks even less risky (even though I don't know if a Github PR can be merged into two target branches in parallel or requires another branch)...
participants (2)
-
BiT dev
-
c.buhtz@posteo.jp