GSoC Week 9

Summary

In week 9, I did two things:

1. Send out a v3 for git mv (from-in-to-out).
2. Explore git grep and try to integrate with sparse index.

Good news this week: rm is in the next branch, hooray!

I found that a verbatim development log is both hard to write and read, so I decided that I should only catch the interesting moments which may be educational or amusing :)

git mv

Here is the v3 for git mv. At the time of writing, it is in the ‘next’ branch.

This is is a re-roll based on the suggestions from reviewers (especially my mentor Victoria) on the mailing list. Nothing groundbreaking.

Commit message running wild

One of the nits is that, when I was writing the commit message of one of the patches, I forgot to update the message along with the interactive rebase modifications. That basically means, the message in the commit is completely outdated and does not describe the actual behavior at all and I totally did not realize. This is fixed in this re-roll.

Oops, a loophole!

A functional change is that I make the <destination> also accept a file path (and behave correctly). Before this version, <destination> is expected to be a directory, because “out-of-cone” was assumed by me, to be a directory. I couldn’t say I was wrong, because that is what “out-of-cone” means, since cone mode always expect directories rather than file paths. However, based on git-mv’s definition, you can use <destination> as a file path, where the desired file is out-of-cone, totally valid.

What’s interesting is, this bug is found when I was adding tests suggested by my mentor. I was quite confident adding the missing tests, praying that the expected result should pop up, and things directly went south when I see the actual outputs. It proves again and again the importance to write comprehensive and correct test cases. Tests are better (reasonably) overprepared than underprepared, always.

Pointer or not pointer, that is the question

This is a funny one. I was writing a commit message, and I want to put the actual code change, which is a pointer, in my log. Then I just write the dereferenced form, e.g. “*a_pointer”, in the log. The actual thing I want to write down is “a_pointer”, without the asterisk. I don’t know, perhaps I think “*” carries more of the spirit of a pointer and without the “*” GCC is going to scream “YOU HEATHENS!”. Nevermind, that’s a joke.

out-to-out, the wild territory

As for now, the mv series covers 3 circumstances:

1. from-in-to-in
2. from-out-to-in
3. from-in-to-out

Well, the fourth one, i.e. from-out-to-out, is still missing. Hope we can see it soon! A NEEDSWORK is added in the code.

git grep

To my surprise, the integration here spends most of the time finding a better user experience, or a more reasonable one, instead actual coding.

In this series, the first step is to add a --sparse option to git grep. I enjoy this little trip of adding an option to Git command pretty much, cool gig hahaha.

The major concern then, is “Should --sparse expand a sparse index without checking if the <pathspec> needs a sparse index?” Here’s my thought, after experimenting several hours with different approaches:

If the user is using --sparse already, then she wants to look at things that are sparse; and when sparse-index is enabled, she probably wants to open the sparse directory entries. Because if we have --sparse specified, what good does it do if we don’t open up sparse directories; if the user somehow specifies a pathspec that has no chance to match things within sparse directories (out-of-cone), why does she specify --sparse , which seems useless?

So, the conclusion is, a “--sparse rules all” mode, where --sparse directly opens a sparse index, seems more reasonable and less hassle, which is an extra credit.