Community Bonding: Week 1
It has been a week and a few days since the start of GSoC’s Community Bonding period. Like I mentioned in my proposal and the previous post, my primary goal for this period is to familiarize myself with the reftable sub-project’s codebase and gain an understanding of reftable’s underlying workings. This has been the epicentre of my focus for the past week, besides working on the other goals I mentioned in last week’s post.
Goals accomplished
- Set up my Payoneer account: I had to face some challenges with setting up a Payoneer account to recieve the GSoC stipend but with the help of GSoC support, I was able to finish this task by this week.
- Set up this blog: A good amount of this goal was already accomplished when I wrote my first blog post last week, but there were a few finishing touches and customizations I wanted to perform which I completed over the last week.
- Go through Git’s relevant documentation: There are some Git documentation besides the reftable ones which are of particular importance in this project, like Git’s Coding Guidelines because one of the goals of this GSoC project is to refactor the reftable tests according to Git’s coding standards. Another documentation of interest is the Pro-Git book’s ‘Git Internals’ chapter which outlines Git’s underlying data structures (particularly the refs and tags backend) in an easily-digestible manner. Although I was already somewhat familiar with these documents due to my contributions pre-GSoC, I went over them once again this week to refresh my memory.
- Finish reading up the reftable documentation: The official Git reftable documentation comprehensively outlines the functioning of the reftable backend. My initial plan was to understand reftable’s internals solely through this documentation, but as I went through with this plan over the past week, I discovered that the documentation was long and technically dense which rendered simply reading over the documentation unfruitful. Nevertheless, I covered a good portion of documentation and skimmed over what I couldn’t understand this week.
Since my original plan of understanding reftable’s codebase with the help of reftable’s official documentation did not work very well, I decided to change my approach to using the reftable backend as an end-users and debugging through the code to see what’s happening in action. This plan proved to be better than the last one but it was still somewhat confusing because every single reftable operation touches a large portion of its codebase making it difficult to keep track of what action each function performs. I decided to modify this plan further and instead of debugging my actions as an end-user, I decided to debug the already present tests for reftable. This approach proved to be the most suitable as each test exercises only a small part of reftable’s code and that makes it much easier to keep track of individual functions as well as the overall picture.
Next week’s goals
I plan to use the new approach I mentioned above in the upcoming week to progress towards my goal of understanding reftable’s codebase in-depth. I have already covered the code in basics.{c,h} and understand it to a pretty good extent, and covered some basic parts of stack.c. I will continue studying the rest of stack.c in the upcoming week and modify the plan further if necessary (hopefully not).
Challenges
I faced some difficulties with understanding reftable’s codebase and formulating an appropriate plan to accomplish that goal but I believe I have found a good approach which I can use to incrementally work towards the goal.
Another challenge I faced was finding a suitable reftable patch to work on. With my pre-GSoC contributions, I would find an appropriate issue to work on by searching for keywords like ‘NEEDSWORK’, ‘TODO’, and ‘FIXME’ in Git’s codebase using grep/git-grep but this approach doesn’t work with reftable’s codebase. Searching for these keywords in the reftable directory doesn’t output anything useful. I am currently occupied with understanding the codebase so this isn’t something I’ve explored deeply or care much about as of now, but after I gain a non-trivial understanding of the code and want to apply that to an actual patch this is surely something I’ll have to tackle.
Till next time,
Chandra.