Topic 3 (introduction to version control) should initialize the repository in GitLab

[fbristow]

While I (me, Franklin) want to introduce version control as a local-first thing (i.e., you don't actually need GitHub or GitLab or whatever to do version control), doing version control as a local-first operation and then later trying to integrate with an online service leads to unnecessary complication and headaches. The specific issue we're seeing is:

1. mkdir my-new-project
   cd my-new-project
   git init -b main
   # do stuff
   git add .
   git commit -m "first local commit"

2. Make a new project in GitLab (or GitHub or whatever). These tools then optionally and helpfully offer to add something to your repository like a README.md, adding README.md involves making a new file and then committing to the repository.

3. Trying to connect the local-first repository with GitLab (or GitHub or whatever) by adding it as a remote leads to divergent histories:

   git remote add origin https://github.com/you/my-new-project
   git push # fails, remote already has commits.
   git pull # fails, remote already has commits.

Two ideas to avoid this situation are:

1. Continue to treat version control and git as local-first. When we get to the next part of version control that requires us working with a remote, make a new and different project.
2. Create the remote project first and then clone the project, skipping git init.

Philosophically, I like the idea of making sure students know that version control does not depend on any specific third party service (very specifically: GitHub != git). Practically, I like not having to explain to students who have never seen version control that they have created two different projects that have two different histories, and that adding the remote won't work specifically because the two histories have diverged and having to introduce the idea of merging very early.

I think the right way to go forward on this is option 2.

[fbristow]

I think that I will proceed with option 2 before we get into fortnight 3.

@ikaroruan, @drkitt, or @UofMrobg: do you have any feedback about this based on your experience running the course with the initial repository being local?

[drkitt]

I like option 2. It's basically what I had students do when they ran into this issue last year.

Also, the philosophical point you mentioned is kind of addressed in fortnight 4, where the textbook uses a GitHub repository as an example for cloning a repository from the internet. Assuming we're using GitLab for the most part, this would give students an example of how git is separate from any specific service. It would also be useful to explain that git is separate from GitLab in an aside in the fortnight 3 chapter, when git (and I'm assuming GitLab) is first introduced.

[ikaroruan]

I also like option 2.

I understand the importance of ensuring that git and Github/GitLab are different in the textbook. However, as @drkitt mentioned, I eventually tell the students to delete the local copy of their repository and do a git clone.

[fbristow]

Philosophically I want students to know that git treats local as a first class citizen, you don't need any remotes for git to work. I'll try to work that in somehow.

This is complete in ece7bfe.