Git Adventures && TOML Config

What I got Through So Far

This week, I learned to create a draft pull request and later change its status to “ready for review. Firstly, i created an issue.After that, i cloned the project and created a branch and made a pull request.My mistakes with Git are decreasing day by day as I gain more understanding of the commands and exposure to Git workflows.

Accepting Pull Request and Communication

While contributing to a TypeScript project, i got a pull request from my groupmate. I analyzed the pull request and i got impressed .The new code was ready to merge, but the only remaining task was to modify bracket formatting and comments in the config_manager.cpp file. After those changes were made, I accepted the pull request.

Code Challenge

When I first saw the feature requirement for a TOML config file, I had no idea what TOML was. I checked the open-source TOML implementations. I used smol-toml to parse. Also, i read about TOML. So far, i started writing code and i created config.ts module and wrote interface ConfigOptions.

export interface ConfigOptions{
     output?: string,
     include?: string,
     exclude?: string,
     tokens?: boolean,
     maxFileSize?: number,
     maxTokens?: number,
     summary?: boolean,
     recent?: number,
     verbose?: boolean
}

I could understand TypeScript intuitively because in C++, we use std::optional instead of ?for optional values.
I used a loadConfig() function to load config options. First, I checked whether the path exists:

if(!fs.existsSync(pathToConfig)){
       return {};
     }

Then i parsed the file content based on ConfigOptions then i handled the error in a graceful way. Finally, I created a helper function in cli.ts to merge TOML config values with CLI arguments, allowing CLI arguments to override config file values..repoPackager.toml file looks like this:

toml
output = "custom-output.md"
verbose = true
tokens = true
exclude = "*.test.ts,*.spec.ts"
maxFileSize = 50000


This file allows users to specify command arguments in a config file instead of typing them one by one in the terminal. At the end, as always, I forgot to add documentation for the new feature in README.md. I added the data and made my second commit to draft pull request. Then I marked it as ready for review.

Git Adventures

This week, i mainly used git branch -m oldName newName command.Because,
i was supposed to change the branch name to reduce the confusion. Also i learned the difference between origin and upstream deeply thanks to this resource. I realized that it is better to do git fetch for downloading remote branches and git merge for merging the code instead of using git pull which can easily create a merge conflict(because it does git fetch and git merge at the same time). When i want to check the pull request to my repo, i need to use git add -a newName forkedVersion to see the changes. This week so far, except for git restore filename i have not suffered a lot in git