Merging Makes the Spice Flow
Tags: opensource, python, github, git
Published: 2020-10-05 02:51:01

This week in OSD600 we're discussing `git merging`; not a super challenging topic (though it certainly get hairy) but definitely one of the most important in learning `git`. Moreover, our lab this week is to add two optional features to our ever-changing [link-checking project](https://github.com/chrispinkney/He-s-Dead-Jim). The two features I chose are:

- Make sure the program honours the `CLICOLOR` environment variable. If `CLICOLOR=1` is set, the program can use colours in the output. If `CLICOLOR=0` is set, do not output any colour.
- Make sure that the program exits with an appropriate error code. If there are no errors (all links are good), exit with `0`. Otherwise, exit with a non-zero exit code.

Not the most challenging features to add to our program but the implementation difficulty is not the point of the lab. In fact right from the get-go I already made a mistake I will hopefully correct sometime between now and the heat death of the universe:  *I always forget to create a separate git branch when implementing additional features.* One of these days I'll get it.

The first feature was implemented quickly due to the flexibility of Python, no types to worry about, no dangling curly braces (*what the hell are those braces called anyway?* [*Oh.*](https://en.wikipedia.org/wiki/Bracket#Curly_brackets)), nothing to make this take any longer than it has to. I started by raising an issue on the project's [GitHub issue page](https://github.com/chrispinkney/He-s-Dead-Jim/issues/19), and then implemented it. You can see the issue's commit [here](https://github.com/chrispinkney/He-s-Dead-Jim/commit/f3cd3bb7c724006a10d83382c8005dc0f3e808df).

The second issue was more interesting to implement and required [a quick search](https://stackoverflow.com/a/285326/13809136) into something I didn't previously know about:  Exit codes in Python. I raised the issue [here](https://github.com/chrispinkney/He-s-Dead-Jim/issues/21), and you can see the commit [here](https://github.com/chrispinkney/He-s-Dead-Jim/commit/57829ef3995542702e66256786ec4d3c06174f7f).

Now it was time for the moment I've been waiting for. The merge of two conflicting branches into master.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/mzwhkwdlo8syyni5pht2.gif)

I implemented both features, `git checkout`'d back to master and merged my first branch. Success, as expected. Rubbing my hands together and sweating profusely I readied myself for those sweet, sweet merge conflicts. I could barely contain myself as I merged the second branch into master...

```
(venv) C:\Users\Chris\Documents\Code\School\OSD600\He-s-Dead-Jim>git merge issue-19
Updating 779ce63..f3cd3bb
Fast-forward
 hdj.py | 64 +++++++++++++++++++++++++++++++++++++++++++++-------------------
 1 file changed, 45 insertions(+), 19 deletions(-)

(venv) C:\Users\Chris\Documents\Code\School\OSD600\He-s-Dead-Jim>git merge issue-21
Auto-merging hdj.py
Merge made by the 'recursive' strategy.
 hdj.py | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)
 ```

Oh... But that's... fine. I guess. Yeah sure git is wonderful... I guess. Whatever...

But that's the neat part about git: three-way merging, as specified by: `Merge made by the 'recursive' strategy.` Since there wasn't really any truly conflicting code there was no reason for git to throw its hands up in the air and sourly exclaim that it couldn't do it. It just works.

I have had to fix a merge conflict once or twice though, I remember hating the experience each time. Hopefully with some more experience and knowledge under my belt (as if my belt fits me anymore. Thanks Covid.) my next `git merge` will go much smoother.

Though from the lecture I did learn more about the wonders about [GitHub keywords](https://docs.github.com/en/enterprise/2.16/user/github/managing-your-work-on-github/closing-issues-using-keywords). Neat!