Summary of this week
At this stage, the main focus is making
git-sparse-checkout work better
git-mv. Read the previous blogs on GSoC to get a better context.
What’s going on in PATCH v4
This week PATCH v4 is addressing reviews from WIP v3. And a major change is that the WIP prefix is removed from this patch iteration, which means that all the functionality part has been done, and this patch is ready for merge review.
For the detailed changes, I put the cover letter of PATCH v4 below, it tells everything. You are welcome to click in PATCH v4 and see each change in detail!
Changes since WIP v3
Move “mv: update sparsity after moving from out-of-cone to in-cone” to the (2/7) position (was (7/7) position in WIP v3). Make this move so that we can drop
git sparse-checkout reapplyfrom the tests, as suggested by Victoria. The reason is we need to check out the moved
cache_entryfor all out-of-cone to in-cone moves, so this commit works better if being the first one.
Fix the commit message of “mv: use flags mode for update_mode”, as suggested here.
Add “Helped-by” and “Suggested-by” trailers.
In “mv: add check_dir_in_index() and solve general dir check issue”, change the
check_dir_in_index()to no more accept
namelenas argument. The original
namelen + 1logic can be erroneous, for example when
namealready has a trailing slash. So just use
strlen()to save the trouble.
As discussed in WIP v3, we can postpone the “in-cone to out-of-cone” move to a later series. Hence, this series’ functionality part has been done, remove the WIP prefix.
What’s learned this week
Make sure a commit does one thing, and the commit message should describe it well. An atomic commit makes the history more reasonable and helps the future developers to clearly see the intention and result of it.
Don’t forget to credit people who helped you. By using “Helped-by” and “Suggested-by” trailers, people helped you can also be recorded into the history. One of the best ways to be grateful. If you find this etiquette interesting
Read the documentation. I haven’t read the CodingGuidelines thoroughly. It specifies all the styling conventions and things to be careful about. One of the consequences of not spending 15 minutes going over the doc, is keeping making styling mistakes like me: I have taken a tab width of 4 spaces for granted, and didn’t expect the Git project uses a tab width of 8 spaces in the C files. This misunderstanding always makes my code looks wrongly indented. Keep calm and read the doc.
Next week is mainly wrapping up this series. For now I have received
a few reviews about adding extra tests. Nothing major from the
reviewers, so hopefully this series can be satisfactory next week.
If everything seems smooth, we can embark on integrating
sparse-index very soon, that’s quite exciting!