New chapter: Gerrit

content/books/things-i-learnt/_index.md

@@ -34,6 +34,7 @@ template = "section-contentless.html"
 	* Source Control
 		* [Always Use A Version Control System](always-vcs)
 		* [One Commit Per Change](one-change-commit)
+		* [Gerrit Is A Mistake](gerrit)
 	* Project Organization
 		* [Organize Your Code by Data/Type, Not Functionality](project-organization)
 		* [Create Libraries](libraries)

content/books/things-i-learnt/gerrit/index.md

@@ -0,0 +1,36 @@
++++
+title = "Things I Learnt The Hard Way - Gerrit Is A Mistake"
+date = 2019-07-29
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "git", "gerrit"]
++++
+
+I hate calling software "a mistake", but I can't find any other way to
+describe Gerrit. You may see people using Gerrit 'cause Google uses it. The
+thing is: Google misunderstood what Git actually is.
+
+<!-- more -->
+
+When Linus Torvalds came with Git, he was trying to mimic another system,
+BitKeeper. Along with some improvements over CVS and SubVersion, Git made
+really easy to create and merge branches, something that was either
+almost-not-supported or slow-as-heck, depending on which tool you look at.
+
+You need to take this into consideration: Git made branches easy.
+
+Then someone came with the idea of Gerrit: Instead of managing branches, it
+actually manages _commits_. Instead of having a branch for each feature, you
+should have _one single commit_ as feature. You can have branches on your
+machine, but the server only deal with commits.
+
+So Gerrit took Git, a tool that improved the way we deal with branches, and
+removed branches. This is akin to taking a text editor and taking away the
+ability to _edit text_. Does that sound right to you?
+
+In my personal opinion, what they did was to take git apart and put an err in
+the middle: gERRit.
+
+When I see someone using Gerrit, I know something is wrong there.
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/one-change-commit", prev_chapter_title="One Commit Per Change", next_chapter_link="/books/things-i-learnt/project-organization", next_chapter_title="Organize Your Code by Data/Type, Not Functionality") }}

content/books/things-i-learnt/one-change-commit/index.md

@@ -36,4 +36,4 @@ the changes in the file before committing.
 [^1]: Ok, it _may_ have some issues if the field can't be null, but you get
   what I meant, right?
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnt/project-organization", next_chapter_title="Organize Your Code by Data/Type, Not Functionality") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/always-vcs", prev_chapter_title="Always Use A Version Control System", next_chapter_link="/books/things-i-learnr/gerrit", next_chapter_title="Gerrit Is A Mistake") }}

content/books/things-i-learnt/project-organization/index.md

@@ -81,4 +81,4 @@ transformations and such, but without the Data3 part). By breaking by their
 types, I managed to create small modules for each one and the new project
 would simply reference Data1 and Data2, but not Data3.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/one-change-commit", prev_chapter_title="One Commit Per Change", next_chapter_link="/books/things-i-learnt/libraries", next_chapter_title="Create Libraries") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/gerrit", prev_chapter_title="Gerrit Is A Mistake", next_chapter_link="/books/things-i-learnt/libraries", next_chapter_title="Create Libraries") }}