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 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