GSoC Week 3



A great week!

Finally a good week happened! The lockdown in my college vicinity got lifted and hence there is a different feeling of joy! Freedom has much more importance now! set-branch is almost done with (v4 in review) hence I have finished the conversion of 2/4 subcommands. Feels great! Though as per my proposal I should be working on improving CLI parsing, but my instinct is to go for the conversion of summary. Let’s see how that goes.

There’s a lot of stuff on my plate right now (my research work, GSoC and self-studies), but who wants to give up huh? It feels nice to be so occupied I don’t know why! Now coming back to GSoC, this week was more of a “touch-up” phase for set-branch (more on that below).

The touch-ups

The command was in a working state in its v1 though it had major redundancies in it (something which I had to get fixed after advise from the experienced ones of Git). After fixing up a couple of things, and converting the branch option from OPT_BOOL to OPT_STRING, things got way simpler than I could imagine! Turns out that OPT_STRING takes the optional argument(s) in as well therefore in my case, branchname ($branch) was the optional argument and it got parsed out of the argv[] array, leaving the only argument as the path which was common to both the default and branch option therefore simplifying everything thus leading to a v2. I had another commit in v1 which aimed at bringing out the utility of the quiet option but it was deemed unnecessary by Denton, Christian and Eric because the subcommand had nothing to quieten.

Now, coming to the v3; it had two small mistakes: 1. There was no mention of the utility of quiet (if it is even being used or not) and 2. A return variable was needed as the module_set_branch function returned 0 even in failures not related to the subcommand (such as lack of space on disk). Junio pointed out (1) and Dscho pointed out (2). Therefore I added a comment to address (1) and added a return variable to address (2). Thus a more clean v4 is out for review now.

What I learned?

The simpler the code is, the more professional and clever it looks. Unnecessary sophistication is the equivalent of fool’s gold, looks good and valuable, but really isn’t. Though I obviously did not complicate the code intentionally, but rather due to my novice-ness it became like that.

The second teaching is, silence is golden. There is no need to prompt things all the time (something which is common in Linux and real life?). Thank you Eric for the tip.

And the final one, comments should be not confusing. to solve the 1st issue in v3, I put up a comment which was:

The quiet option is present for backward compatibility but is currently not used.

Do I even need to explain how ambiguous this is (something which took me one whole patch to realise)? Thus after help from Christian, I changed it to:

We accept the quiet option for uniformity across subcommands, though there is nothing to make less verbose in this subcommand.

which seems way better! Thank you Junio!

What’s next?

As I said before, My next goal is to convert summary to C. But before getting right into the conversion, I will look into Git’s callback API and understand what exactly is going on in it. What is confusing me is the need of the API and child processes. I think I will spend a couple of days in understanding this as well as create a scaffolding for the subcommand (something which I had done before too but I aim to refine it even better now).

Over and out,
Shourya Shukla

Location: Roorkee, Uttarakhand, India

Comments

Post a Comment

Popular posts from this blog

The Final Report

The Final Report This blog will describe my GSoC project along with a small account of how I started contributing to Git. My GSoC '20 project was to convert 'submodule' to a builtin by porting it from shell to C. Initially, Git commands were written in shell with some instances of Perl as well. As times progressed, various platforms to run Git emerged & projects became large (spanning millions of lines of code), enter, problems in production level code, such as: Difficulties in portability of code. The submodule shell script uses commands such as echo, grep, cd, test and printf to name a few. When switching to non-POSIX compliant systems, one will have to use emulation layers to implement such commands on the system. Which is a lot of extra work. There is large overhead involved in calling the command . As these commands implemented in shell script are not buitlins, they tend to call multiple fork() and exec() syscalls for creating more child p...
Read more

GSoC Week 4 [One month special]

 One month complete! A month has passed now since GSoC started (it will on June 4) and it is a fine milestone I think! I feel happy about it. This week was more about studying things and what is under the hood rather than programming something like it has been always. I was stuck with the callback mechanism of the submodule code. I could not understand the purpose behind it and thought that it was not needed. But as always, the things which confuse me are the ones with very simple and crystal clear logic behind them (but again, not to fret, we learn to walk by falling over and over right?); I will cover the callback mechanism in the blog so that anyone who ever wants to work on submodules or a future student like me has some reference to what is going on. What are callbacks? Callbacks are defined in regard to a function or a segment of a program you call when encountered with a particular trigger (such as an if statement or end of function). And by “you call”, I ...
Read more

GSoC Week 10

Addressing comments on my patch I spent this week addressing the suggestions made by Johannes which, were extremely detailed and long. I am done with most of the suggestions so I will highlight some important ones and what I learned from them. This week, I saw the ocean for I guess the first time in my life and it was a totally unique experience! Peaceful Seas Moving to the comments made by Johannes. Eliminate find_unique_abbrev() The shell version of summary calls git rev-parse twice for two jobs which are: Checking for a missing_src and a missing_dst i.e. , the missing source and destination committish. test $mod_src = 160000 && ! GIT_DIR="$name/.git" git rev-parse -q --verify $sha1_src^0 >/dev/null && missing_src=t test $mod_dst = 160000 && ! GIT_DIR="$name/.git" git rev-parse -q --verify $sha1_dst^0 >/dev/null && missing_dst=t Quoting my mentor Kaartic: The above code assigns missi...
Read more