In week 9, I did two things:
- Send out a v3 for
git grepand 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 :)
Here is the v3 for
git mv. At the time of writing, it is in the ‘next’
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,
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
<destination> as a file path, where the desired file is out-of-cone,
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:
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.
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
--sparsealready, 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
--sparsespecified, 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
directly opens a sparse index, seems more reasonable and less hassle,
which is an extra credit.