Intro
For my Open-Source class this week I collaborated with a classmate to add a new feature to their text-to-HTML converter adding support for TOML configuration files.
Before beginning contributing with this addition I familiarized myself with their project's code and structure while beginning to think about how I was going to implement it.
Contributing
To start, I created an Issue in my classmate's project detailing what I was going to add and how I would add it.
To add support for TOML files I first needed to find a proper .toml
file parser that would be compatible with my classmate's project in Python. I ended up using the tomli on recommendation from the project owner for parsing program options from a .toml
file. The tomli library was added to version 3.11 of Python.
After being approved to work on the project I began to implement the tomli TOML file parser in my classmates' repo. Their project was separated into many different modules which made adding any changes easier as I wouldn't have to update as many functions as they all referenced one module.
The module in question dealt with command line arguments passed to the program and used Python's argparse library to export an object of required program options that are used around the program. In this module is where I would do most of the work by adding a -c
, and --config
argument option using argparse that accepted .toml
files, then adding a check to see if a config file was passed where if there was it would process and overwrite any program options with ones in the file.
I then sent the changes as a pull request and after updating the readme and some other things requested by the maintainer my addition was merged into the main project.
Reviewing a Pull Request with Git Remote
In my own text-to-HTML project, I also received a pull request adding support for TOML config files.
Once the pull request was made I then needed to review the change and test it. To do this I set a remote to the forked branch of my repo and then fetched the contents into my repo.
$ git remote add <name-of-student> <https://git-url-of-other-studnet-fork.git>
$ git fetch <name-of-student>
I then created a new branch with the remote additions added to my main repo so that I could test the new additions as if they were merged:
$ git checkout -b <branch-name> <name-of-student>/<branch-name>
This allowed me to easily make updates or pull any new changes the contributor makes.
After reviewing the pull request I saw it was good to go I used:
$ git merge <student-name>/issue-10
which automatically merged the pull request into my repo from my created remote mentioned above.
Final Thoughts
After completing these activities, I've learned a lot about remotes and how they can be set up to directly work with pull requests which is very useful for reviewing. I also was able to view another person's code and test my ability to add and try to emulate how the code was used which improved my overall skill.
The difficulty that I encountered when working on these was that I made the mistake of adding the remote branch of my repos forked pull request branch to the repo of another project. Thinking that I screwed up I ended up learning how to remove remotes by using git push origin -d
to delete the remote branch from the incorrect repo.
Top comments (0)