Hi Shourya, Thank you for this series! Please see the comments below: On 2020.10.07 13:15, Shourya Shukla wrote: > Hello all, > > This is the v2 of the patch with the same title, delivered more than a > month ago as a part of my GSoC. Link to v1: > https://lore.kernel.org/git/20200824090359.403944-1-shouryashukla.oo@xxxxxxxxx/ Since GSoC has ended for the year, I wanted to point out the git-mentoring@xxxxxxxxxxxxxxxx list, where you can find additional mentors if you like. > The changelog is as follows: > > 1. Introduce PATCH[1/3](dir: change the scope of function > 'directory_exists_in_index()', 2020-10-06). This was done since > the above mentioned function will be used in the patch that > follows. > > 2. There are multiple changes in this commit: > > A. Improve the part which checks if the 'path' given as > argument exists or not. Implementing Kaartic's > suggestions on the patch, I had to make sure that the > case for checking if the path has tracked contents or > not also works. > > B. Also, wrap the aforementioned segment in a function > since it became very long. The function is called > 'check_sm_exists()'. > > C. Also, use the function 'is_nonbare_repository_dir()' > instead of 'is_directory()' when trying to resolve > gitlink. > > D. Append keyword 'fatal' in front of the expected output of > test t7400.6 since the command die()s out in case of > absence of commits in a submodule. > > E. Remove the extra `#include "dir.h"` from > 'submodule--helper.c'. > > 3. Introduce PATCH[3/3] (t7400: add test to check 'submodule add' > for tracked paths, 2020-10-07). Kaartic pointed out that a test > for path with tracked contents did not exist and hence it was > necessary to write one. Therefore, this commit introduces a new > test 't7400.18: submodule add to path with tracked contents > fails'. Generally, we want to avoid describing in detail what the code does; hopefully, the code can speak for itself. It may be a better use of the cover letter to describe the motivation for the series as a whole. Reviewers will not necessarily have background on what you want to accomplish. We came up with a few factors that might have inspired this change, but we're not sure which you intended to address: * Increase efficiency by reducing the number of processes forked and the use of the shell. * Make the submodule code easier to maintain (since the project probably has more C experts than shell experts). * Improve the user experience with submodules by giving the submodule-add code access to C internals, and vice versa. Knowing what you want to accomplish can make it easier for reviewers. Of course, you'll also want to include important context in your commit messages as well, so that it's available in the history if future debugging is necessary. Thanks again for the series, and please feel free to follow up if you have any questions -- Josh
