GSoC Week 2

Summary of this week

At this stage, the main focus is making git-sparse-checkout work better with git-mv. Read the previous blogs on GSoC to get a better context.

This week I’m working to ship a PATCH v4 (please reference all the code here) to address the issues raised in WIP v3.

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

1. Fix style-nits.

2. 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 reapply from the tests, as suggested by Victoria. The reason is we need to check out the moved cache_entry for all out-of-cone to in-cone moves, so this commit works better if being the first one.

3. Fix the commit message of “mv: use flags mode for update_mode”, as suggested here.

4. Add “Helped-by” and “Suggested-by” trailers.

5. In “mv: add check_dir_in_index() and solve general dir check issue”, change the check_dir_in_index() to no more accept namelen as argument. The original namelen + 1 logic can be erroneous, for example when name already has a trailing slash. So just use strlen() to save the trouble.

Notes

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

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

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

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

What’s next

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 mv with sparse-index very soon, that’s quite exciting!