OSD600 - lab05

Description

This post is about lab 05 for OSD600 course at seneca college.
This week, the students are required to learn and practice git rebase and git commit --amend. First we were required to refactore our code and make a commit for each refactoring. After finishing all the refactoring, we were to rebase the commits with main branch, and squash all the commits made while refactoring into one commit. Finally, we amend the final commit.

Process of Refactoring

Goal

For this refactoring, what I focused most on the SOC(Seperation of Concern). Second, I focused on encapsulation.

Steps

1. Loading.codemage-config.toml file from home directory was called twice in different files. I thought that this is really inefficient. So I tried to make it called only once.

2. I had total 4 files: main(codeMage.py, api.py, translator.py, loadConfig.py). Most of the files had only one function. The function had all the logics to do a task. For example, translator function had all the logics for verifying target language, source language, output file name, and calling api function. Readability was disastrous. What I did first was encapsulating the function as a class and made some of the variables as class attributes and created private methods for other logics such as verying traget_language or getting output file name. As as result, translate() only contains the necessary logic for calling llm_api.

3. Likewise, I made a class for call_api function, which is located in api.py file. I also made class attributes for api_url, api_model, and api_key. I focused the call_api method on creating Client request and Completion response.

Things that were challenging

The thing that I was most afraid of was breaking the code. At least it was working well if the code was somewhat dirty. Therefore, I tried to make as small changes as I can. And also, I didn't delete the previous code; I just made commented them out. Only after I made sure the refactored code works fine, did I deleted the code.

Thoughts on Rebase

Maybe I am wrong; however, I think Rebase is not a new thing. It's just a reverse version of three way merge. Three way merge is, merging the issue branch into the main branch; on the other hand, rebase is bringing the main branch on the bottom of the issue branch. Things that happen while performing rebase is basically the same with what happens while doing three way merge. If there is conflicts, you need to solve it, and if not, they are just smoothly combined. In conclusion, rebase is sort of a trick. In a simple way, merge is putting your new commit into the middle of main branch commits(it could be top), and rebase is putting your new commit on top of the main branch commits.

Plan for Rebase Experiment

c1, c2, c3, c4, c5, c6 - main branch
c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - new issue branch

In this lab what we have done is, squashing c7~c10 based on c6 commit, and then make it look like:

c1, c2, c3, c4, c5, c6, c11.

However, I wonder if the follwing is possible.

c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - main branch

From here, I checkout a new branch with c6 commit.

Then the new branch will be:

c1, c2, c3, c4, c5, c6, c7, c8, c9, c10 - main branch
c1, c2, c3, c4, c5, c6 - new branch

And first I squash the commits c4, c5, c6 the new branch woud look like:

c1, c2, c3, c11.

Then, Cherry-pick the c7, c8, c9, c10 from main branch into the new branch.
If this works, it would look like:

c1, c2, c3, c11, c7, c8, c9, c10

To play safe, I should make a new branch for copying main branch. And then after all things are done, checkout -B.
However, I have no idea if it would work, but it looks like an interesting experiment.

If I succeed in doing this, I think I would feel like I am the master of space and time in git.