week3-4

When I started studying git worktree, I went through a period of mental confusion. At first, I started studying the documentation to get familiar with the command, which differs significantly from other commands: it manages multiple working trees attached to the same repository. I spent a lot of time understanding this concept, and it was only after trying to use the command that I understood how it should be used. However, I was still puzzled by this concept. I wondered how it was related to the index, since it creates a new working tree each time. When I was confused, I thought I should seriously study the source code and look for places where it interacts with the index.

I eventually found two places related to the index:

  1. The ‘validate_no_submodules’ function, which checks if there are any submodules present in the worktree.

  2. The ‘check_clean_worktree’ function, which verifies if a worktree is ‘clean’, i.e., there are no untracked or modified but uncommitted files. This is done by running the ‘git status’ command, and an error message is thrown if the worktree is not clean. Given that ‘git status’ is already sparse-aware, the function is also sparse-aware.

So the next steps were quite similar to those with diff-tree, as we had evidence to show that we didn’t need to do any extra handling of the index. Finally, we didn’t see a significant improvement in performance testing, mainly because the time taken to read the index is minuscule compared to filesystem operations.