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 15

Feedback on the patches Finally, I submitted the patches about ten days back (yes, I missed the previous blog because I kind of forgot about it). The patches got fine feedback and required some changes to be good to go. On t7401: modernise cleanup and warn The patch was well received though needed some changes in the commit (t7401: modernise style, 2020-07-23) . It was better to redirect the output of the rev-parse to a file and then cut the output using cut -c1-7 instead of using the pipe | operator. Also, Taylor Blau and Junio C Hamano suggested I drop the commit (t7401: ensure uniformity in the '--for-status' test, 2020-07-10) since the change it made could be combined with the commit (t7401: change test_i18ncmp syntax for clarity, 2020-07-10) . I also introduced a commit (t7401: change indentation for enhanced readability, 2020-08-11) which improves the indentation of the tests in the script for enhanced readability*. Also, the commit (t7401: add
Read more

GSoC Week 7

Taking decisions This week was an even more deeper dive into git submodule 's code. I am almost done with the module_summary frontend function. My set-branch port will move to next on git/git hopefully! I learned even more about shell scripting and the shell code of summary . This time, I will present my thoughts here on what I have learned. There may seem to be a bit less information here because of the relatively early write-up of the blog because I finally leave for my home this Friday! <3 Anyway, moving on to the important stuff Current Progress As of now, the module_summary() (the frontend function for the summary subcommand) is almost done with. I have successfully ported it from shell taking some inspiration from Prathamesh’s patch as well. Prathamesh’s patch had 6 functions namely module_summary() , compute_summary_module_list() , submodule_summary_callback() , prepare_submodule_summary() , print_submodule_summary() and finally verify_subm
Read more