Merging It All Together
Pun intended. Everything I’ve been shown and taught so far in Git was tested this week - from the basics like pulling and committing to creating issues, branches, merges, and the rest of the lot. Let me just say it right now, mistakes were made.
While working to add a new feature to my link checking tool, Haystack, I’ve come to realize that one should keep their changes minimal and only edit what needs to be edited in order to add such feature. I’ll repeat it to myself for my own future’s sake — DO NOT TOUCH any other code that doesn’t directly relate to the new feature. I wouldn’t realize my mistake until much later. You see, when I work on my code I always find something that I think can be changed for the better. It can be small things like changing from having vertical white space to none or fixing formatting inconsistencies, to big things like how the code flows, logic changes, or completely changing certain methods that I believe could be coded better. That happened to me when I started to add my first new feature (additional file processing flags)
I created a new branch to start tinkering and immediately found myself fixing formatting inconsistencies all over the place. I went so far to even see what removing all the vertical white space would look like for code readability (note to self: no vertical white space just ain’t for me). Hours spent “fixing” my program, only to realize at the end that I didn’t even know how I would go about implementing this new feature…
To recap, Haystack is given a file in the command line to parse through and check for links. When I first made this program I used Python’s sys.argv to parse the user’s input which worked well for me. Though, the following week of it’s release I accepted a pull request to add the argparse library (a more sophisticated way to parse the user’s command line input). This was great for the functionality of my code but in a way bad for me — I didn’t know how to use the argparse library, let alone add additional command line flags. I spent hours reading paragraph after paragraph of documentation trying to understand and think of a way to add sub commands for the optional file processing flags. Every example I was shown was hard to follow, the documentation a bit vague and short, it was a nightmare. In the end I scrapped my work and went about it a different way, a way that I was more familiar. Instead of making it a sub command, I opted to make it just like any other command that I had. Lo and behold it worked, but it came at a cost.
I had edited the main file so much that when I checked the differences via git diff, I had almost 30 lines of deletions and insertion on a program with originally a total of 90 lines — I edited almost half of the program to add three additional file processing flags.
To make a long story short, I implemented my other planned feature (support for proper exit codes) quite fast only to be met with a new problem. When everything was said and done, both features implemented, it was time to merge. Two words: merge conflict. I had two branches that initially split from the same master branch, but one branch (the one I had worked so hard to add additional flags) was so completely different than my other working branch. Panic struck as I didn’t know what to do, but before my despair settled in I picked myself up and went to work, line by line I solved the merge conflicts. It was a long and tedious task. If I had only edited what I needed to, then I wouldn’t be here…
So yeah, mistakes were made but I can assuredly say that I am a better programmer because of it. In the end I fixed all the merge conflicts and put it all together, Haystack had just been upgraded. I know my lesson now, when working to add a new feature on a separate branch, focus on the code that relates to that feature — all the formatting stuff can wait.
