Git Migration Retrospective

[friarsol]

Hey folks,

I'm making a little poll to go with a small retrospective about the Git Migration to see what types of things we want to tweak or reinforce moving forward. For the retrospective itself, let's do it how we do it at my office.

Things you liked (+1), Things that were notable (0), Things you disliked (-1). You can have as many as you want. Let's keep it relatively on topic: SVN, Git, SVN -> Git Migration, Things being on Git affects.

I'll figure out after we get a bunch of responses what type of action items we have.

If people want to have a general discussion about the items that come up, feel free to post about them in this thread too. I can accumulate the full list in a few days and append it to this post.

[friarsol]

+1 Thanks for Krazy to all his hard work for getting enough momentum for this to happen
+1 Contribution increases
+1 Lots of communication on Discord
+1 Extra pair of eyes on all commits is great
0 But maybe not all commits really need that?
0 Maybe right before a new set wasn't the best time to migrate
-1 Lots of stops and starts to get the migration completed.
-1 Git Server has some responsiveness issues during certain times
-1 Release tools/process still need to be updated.

[schnautzr]

I have limited SVN experience, so Git is just a new interface for me with different terminology. I've been disappointed with the unreliability of the website (lots of timeouts). The interface has a learning curve to it, but I feel like it's gotten easier for me to do what I'm wanting the past few days.

[Agetian]

+1 Big thanks to everyone involved (first of all Krazy, Sol) for getting this started and seeing it through to completion.
+1 Increased collaboration between developers (including discussion features on GitLab)
+1 It's easier for the new contributors to contribute to Forge (provided that they know how to use Git or are willing to learn)
+1 Additional review of commits is a good thing
+1 Fast, responsive and quite easy to manage branches (very good for separating features and bug fixes and managing them upstream later if necessary)
+1 Local copy of the entire Git repository, which each developer has (many operations can be done locally and then pushed upstream into the remote server; also, even if something unexpected happens to the original server, the entire repository can be uploaded elsewhere by any developer who has a copy)
+1 Git is sturdy and error-resistant, it's difficult to make an error with Git that would be completely irreparable and unrecoverable in at least some way
0 Enforcing merge request workflow makes small feature/fix commits rather tedious to get upstream compared to a simple push (but may be necessary to make upstream fully manageable and easily recoverable)
-1 Git server responsiveness can be rather bad, and what is normally tedious (e.g. see the line above) can turn into a nightmare if the Git server doesn't want to cooperate and is lagging for a prolonged period of time.
-1 Release tools still need to be updated, including the build bot to maintain auto nightly builds.
-1 Pushing directly to upstream/master is still a thing, even though it's officially discouraged (sometimes I see a commit or two go directly there... we should really stop doing that).
-1 Basic Git has a somewhat steeper learning curve compared to basic SVN, and I found myself commonly thinking about terminology (rebase, stash, merge, etc.) and planning certain operations ahead more than thinking about coding the game during the early post-migration stages. This is mitigated with experience, but silly mistakes are almost unavoidable for a complete beginner when starting to work practically with Git (we may want to document the procedure of getting a basic Git setup going to contribute to Forge). That said, Git is sturdy and error-resistant, so errors can be corrected rather easily when made.

All in all, the advantages definitely significantly outweigh the disadvantages

- Agetian