Ignore the default branch name problem

[ekohl]

With older versions of git the command to rename the branch fails if there is no branch yet. We're also making the tutorial harder than it needs to be.

This ignores it and simply uses the default by pushing HEAD instead of main. GitHub is then smart enough to use that as default. Future clones will also simply copy the default branch from GitHub.

Fixes #1779

[das-g]

As we give example output of git status and of git push …, shouldn't we at least mention that it might read master instead of main for some? https://github.com/DjangoGirls/tutorial/blob/d6968a0bd761e1a0372b2f967725c7d0aa4b5440/en/deploy/README.md?plain=1#L87-L101 https://github.com/DjangoGirls/tutorial/blob/d6968a0bd761e1a0372b2f967725c7d0aa4b5440/en/deploy/README.md?plain=1#L146-L151

[nikhiljohn10]

As we give example output of git status and of git push …, shouldn't we at least mention that it might read master instead of main for some?

We could inform the reader in the git section that you might find the branch name to be master or main.

[ekohl]

I respectfully disagree that it's a problem. The tutorial is already hard enough and adding more concepts just confuses people. They just have a single branch and that's good enough. They have so many new things coming at them at once that I'm sure nobody will even notice. And as time goes on, it'll simply disappear when more people have a newer git version.

But I'll also note that I'm of the opinion that it'll all virtue signalling and doesn't actually make any difference at all. It still annoys me on an almost daily basis that you now have to remember what the default branch is because only part of the world has switched over. Let's not punish the participants in the same way and make their lives a little bit easier.

[nikhiljohn10]

The movement to change the default branch name was driven by this as far as I know. Github, Gitlab and others are pushing the changes as they all felt the need for change. It is inevitable, the default branch name is going to be main in almost all maintained git software in the near future.

Also, I don't think that the name change is going to confuse them if we mention that "Currently, default branch name is main and previously it was master. You could encounter it in some repositories."

With that said, I hope we can merge this PR until/unless it affects any other technical aspects of DjangoGirls repos.

[thibaudcolas]

If this specific approach is controversial and needs further consideration, perhaps in the meantime we could at least change the tutorial enough so people no longer face the error? There are two options that are really simple:

• Keep all instructions as-is, except git branch -M main, replacing it with git symbolic-ref HEAD refs/heads/main. Works fine in git v2.25.1 (what RunCode uses) and v2.42.0 (latest)
• Keep the instructions as-is but moving the ### Adjusting your branch name section after ### Ignoring files.

Both options will work the same regardless of whether the HEAD branch is main or master.

---

Personally I think this rename step is valuable to retain in a simplified version just for the sake of making sure everyone uses the same branch name, as it simplifies troubleshooting quite a bit. It’s great the tutorial shows the output of git status to explain it, and that contains the branch name, so pushing to HEAD works but is only one aspect.

[ekohl]

If this specific approach is controversial and needs further consideration, perhaps in the meantime we could at least change the tutorial enough so people no longer face the error? There are two options that are really simple:

I don't think it's controversial: it works and makes lives easier.

You may see some cases where the exact example output may differ a little bit, but I doubt students will notice this.

Right now I'm providing a solution to a real problem. I don't see anyone else submitting any alternative. I'm getting really frustrated that there is no movement on this issue.

[thibaudcolas]

@ekohl reading through #1676, #1742, #1779, and now this pull request – it seems reasonable to me to assume others feel differently about this than you do?

With the caveat that I don’t personally help maintain the tutorial – I’d suspect the main reason there’s no movement is that the solution you’re providing essentially undoes a lot of pre-existing work by other people. You’re also suggesting bigger changes (removing all notions of branch renaming for all tutorial users) than are strictly needed to address the problem at hand (make the branch renaming work for users below git 2.28).

I’ve proposed alternatives that I think are suitable right in the comment you’re responding to. I’ve made a PR for the one that has my preference at #1803 if it helps making it clearer it’s a suitable alternative.

[ekohl]

With the caveat that I don’t personally help maintain the tutorial – I’d suspect the main reason there’s no movement is that the solution you’re providing essentially undoes a lot of pre-existing work by other people. You’re also suggesting bigger changes (removing all notions of branch renaming for all tutorial users) than are strictly needed to address the problem at hand (make the branch renaming work for users below git 2.28).

Yes, and I see this as a feature. I've been a mentor at least 8 times and I always notice that most students are overloaded with new information. This is such an irrelevant point for them that it just distracts them from the real work. They can only learn so much in a single day, so let's make sure they learn Python, Django and HTML & CSS. At the events I attended I also heard regular suggestions to drop git, pushing to github & deploying altogether because it's too much and barely teaches them anything. I'm not that extreme, but I do think we should shield them from the default branch problem.

I’ve proposed alternatives that I think are suitable right in the comment you’re responding to. I’ve made a PR for the one that has my preference at #1803 if it helps making it clearer it’s a suitable alternative.

While I disagree with it, I do appreciate you being constructive in presenting an alternative.