GSoC Week 13

Passed the Second Eval!

The results for the second evaluation arrived on the dawn of August 1, and I passed. It felt great to get positive feedback from Christian and Kaartic regarding my performance. Also, I think no one saw my patch regarding t7401, so I will send it once again on the list most probably. Finally, we are done with the v2 of git submodule summary. It was a big rollercoaster, so many bugs and new use cases coming along the way. The one last problem which came in the way may appear to some as very trivial but explains another difference between the shell and the C version.

The Problem

The problem was that when the shell version of summary was run outside of the test suite, it resulted in two newlines being printed at the end of the output (though it printed only one newline when run inside the tests) whereas the C version printed just one newline irrespective of where it was run.

The explanation for inconsistency between the test and non-test output was that some commands, such as git log and apparently, git submodule summary behave a bit differently when run in a test, hence, we got one newline in the test and two outside of it. The output in case of a test was:

$ git submodule summary HEAD^
* my-subm 35b40f1...dbd5fc8 (1):
  > add file2
  <newline>

But outside the tests:

$ git submodule summary HEAD^
* my-subm b9a571f...f87eb26 (1):
  > add file2
  <newline>
  <newline>

But, to explain the difference that we get two newlines in the shell version and one in the C version, we need to recall the final bits of the cmd_summary() function:

	if test $mod_src = 160000 && test $mod_dst = 160000
	then
		limit=
		test $summary_limit -gt 0 && limit="-$summary_limit"
		GIT_DIR="$name/.git" \
		git log $limit --pretty='format:  %m %s' \
		--first-parent $sha1_src...$sha1_dst
	elif test $mod_dst = 160000
	then
		GIT_DIR="$name/.git" \
		git log --pretty='format:  > %s' -1 $sha1_dst
	else
		GIT_DIR="$name/.git" \
		git log --pretty='format:  < %s' -1 $sha1_src
		fi
		echo
	fi
	echo
done

The --pretty part in git log is:

--pretty='format:  %m %s'

or

--pretty='format:  {>,<} %s'

Whereas in the C version:

	if (S_ISGITLINK(p->mod_src) && S_ISGITLINK(p->mod_dst)) {
		if (info->summary_limit > 0)
			argv_array_pushf(&cp_log.args, "-%d",
					 info->summary_limit);

		argv_array_pushl(&cp_log.args, "--pretty=  %m %s",
				 "--first-parent", NULL);
		argv_array_pushf(&cp_log.args, "%s...%s",
				 src_abbrev,
				 dst_abbrev);
	} else if (S_ISGITLINK(p->mod_dst)) {
		argv_array_pushl(&cp_log.args, "--pretty=  > %s",
				 "-1", dst_abbrev, NULL);
	} else {
		argv_array_pushl(&cp_log.args, "--pretty=  < %s",
				 "-1", src_abbrev, NULL);
	}
	run_command(&cp_log);
}
printf("\n");

It is

--pretty=  %m %s

or

--pretty=  {>,<} %s

The difference is that the formatting in the C version is equivalent to

tformat:  %m %s

tformat is identical to format but the difference is that it the entries have a terminator (i.e., a newline) character between them instead of a separator between between them. Due to this, the C output ends on a line after the last commit and then the final printf("\n") creates another newline (which is the <newline> we observe). In the shell version, this does not happen and the two echo calls at the end result in two <newline>s being printed. This difference did not affect the port per se but was to be investigated and recorded.

Documenting for-status

I decided to create a commit to document the for-status option since it was not mentioned anywhere in the submodule Documentation. I had to add the option in the autocomplete git-completion.bash and mention it in the options provided in the shell script usage and the Documentation git-submodule.txt.

Next steps

I have to get the final commit and cover letter reviewed by Christian and Kaartic (which will be hopefully done in the next 24-36 hours) and after that I will post the patch on the List. Let’s see how it goes.

Over and out,
Shourya Shukla

Location: Chennai, Tamil Nadu, 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