Github Repo: Tiller
Adding features
The first functional issue I decided to post about was the ability to give different language headings to the generated HTML files.
The option was added simply by allowing another argument to be passed when calling the CLI. The argument in question was -l or --lang which would take a language argument with the default being en-CA.
Once passed, the language option would be set whilst generating the HTML file, found here
This was finally completed and merged with this pull request
The second functional issue was to add horizontal line support delimited by --- when converting markdown files allowing them to be translated to the <hr/> tag.
Similar to a previous functionality which added <h1> support to my CLI, it was simple to check to see if any of the lines provided featured the triple dash and then converting that string match to the hr tag. The final result looks something like this:
horiz_line = new_text_content.find("---")
if(horiz_line != -1):
new_text_content = new_text_content.replace("---", "<hr />")
The functionality was then merged with a pull-request
Prcoess and Issues of Merging
So funnily enough, it was my first PR that gave me major issues with my second one being a breeze. This was mainly due to accidentally adding additional changes that were brought up to me shortly after the 0.1 release. Changes such as utilizing the os library more and opting to use the os.path module as opposed to how I was handling file names before which was simply using strings. I had to go through some of my files and resolve certain conflicts with all that I had changed in my codebase and then finally merge the new language functionality into my CLI program. Due to how small the second functionality was, it didn't affect much of my codebase allowing for it to smoothly be added with little to no conflicts.
A learning experience
Working in parallel branches was a little scary considering one wrong merge and the entire codebase could potentially be reverted to a broken state. GitHub comes with many fail-safes, which makes working in a parallel branch environment very fun. The experience provided me with a lot of useful insight into how conflicts are solved, risks can be assessed, and multiple functionalities can be worked on at one time.
What would I do differently next time
I would definitely make sure that all major changes I need to make are pushed to the main branch before anything else is worked on. It was something that made merging everything a little harder to do since a lot of lines and checks were changed. Next time I would definitely take more care with what I'm changing in a branch so as to not create a wave of merge conflicts.
Top comments (0)