Yet another week of exploring various Git features in the Open Source Development course is coming to an end.

We returned to contributing to our peers' projects, but this time around, in addition to creating Pull Requests, we had to use git fetch and git remote to test our classmates' contributions and track them throughout the process of implementation.

Adding a new feature to DialectMorph

This week, I worked on adding a new feature to the CLI code translation tool called DialectMorph. The feature introduces support for configuring the CLI tool's default settings using a .toml file located in the user's home directory. (You can find more details here: issue #24).

I almost immediately created a Pull Request for the issue using a nifty draft pull request feature (my Pull Request).

Note: Draft Pull Requests allow developers to share their work before it is ready for merging, fostering early feedback and collaboration.

To implement the new functionality, I added a helper function dedicated to loading configuration options from the .toml file (TOML - library used to parse the file contents):

// helper function to load and parse a TOML config file
export function loadTomlConfigFile(
  configFileName: string = "dialectMorph.config.toml",
) {
  const homeDir = os.homedir();
  const configFilePath = path.resolve(homeDir, configFileName);

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

  const fileContents = fs.readFileSync(configFilePath, "utf-8");
  // parse contents of the config file
  const config = toml.parse(fileContents);

  return config;
}

I then modified the main function to first load the contents of the configuration file using the helper function and merge those default settings with the CLI arguments (giving precedence to the CLI options):

let config = {};
try {
  // load tool settings from the user's home directory
  config = loadTomlConfigFile();
} catch (e) {
  console.error(`Error trying to load config file: ${e}`);
}

// merge CLI options with config file options (CLI options take precedence)
const mergedOptions = {
  ...config,
  ...options,
};

The last step, was adding the information about the new feature to the README.md. And just like that, my PR was ready for review.

Luckily, the repo owner was satisfied with my contribution, so it got merged right away (without me having to make any adjustments to the suggested changes).

Testing someone's contribution using git remote and git fetch

Now, let's move on to the most exciting part of this week's activity: reviewing and testing the same functionality implemented in my project using Git remotes.

My lab partner: Kannav02
His Pull Request: Pull Request #9

How I tested Kannav's code locally using Git:

1. Adding Kannav's Fork as a Remote

git remote add <remote-name> <https://remote-repo-url.git>

Adding a Remote - connecting your local repository to another remote repository, allowing you to interact with it. Adding multiple remotes gives you the ability to fetch from and push to different sources.

1. Fetching the code from the new Remote

git fetch <remote-name>

Fetching allows you to retrieve commits and branches from the remote repository without merging them into your local repo, giving you a way to download the contributor's code without messing up yours.

3 - Setting up a tracking branch

git checkout -b <branch-name> <remote-name>/<branch-name>

Setting up a tracking branch helped me to test, review, and keep track of the changes that Kannav was making on the dedicated branch of his Fork of my repo.

Using git remote and git fetch helped me to streamline the collaboration process. Instead of having to clone the entire fork to keep up with the ongoing changes (my previous approach), I was able to simply add the remote repository and fetch updates as needed.

Afterthoughts

This week's lab went surprisingly smoothly. Although I was initially nervous about using git fetch for the first time, I was pleasantly surprised by how convenient it made the process of testing.