Web lists-archives.com

GSoC Project | Submodules related work

Hey everyone,

I am Prathamesh. I am studying Computer Science and Engineering at IIT
Kharagpur. I am interested to participate in Google Summer of Code 2017
under Git organization. I attempted "Avoid pipes in git related commands
for test suite" as my microproject[1].

As a part of GSoC, I would like to work on git submodules. The projects I
have looked up are:
        1. "git -C sub add ." might behave just like "git add sub"
        2. Teach "git -C <submodule-path> status" in an unpopulated
           submodule to report the submodule being unpopulated, do not
           fall back to the superproject.
        3. Teach "git log -- <path/into/submodule/and/further>" to behave
           like "git -C <path/into/submodule> log -- <and/further>"

I went through the series of mail (related to projects 1 and 2)[2] for
getting a better picture of the projects. I think as the projects are
quite interrelated together, these may make a complete GSoC project.

Also the conclusions which I was able to make from the mails[2] are:

1. We are catching commands typed by the user in an unpopulated or
   even an uninitialized submodule.

2. We first check if we are present in the superproject's root dir.
   If .git dir is present we check for the presence of .gitmodules file,
   from which we can check the path give is inside some submodule.
   *When .git file containing just a .gitlink is present then, I am not
   sure but even in this case the root folder contains .gitmodules
   file in the case of submodules(Please correct me here, if I'm going
   wrong), then we may still carry the same procedure as above.

3. Once we can detect whether the $cwd is in a submodule, we can output
   "The submodule 'sub' is not initialized. To init ..." for all the
   commands which doesn't initialize and populate the submodule.

4. As similar detection could be used in the third project listed above,
   hence I even wished to include it.

What are your suggestions about these projects? Also, will it be
rational to consider it as one complete project for GSoC?
I think this might interfere with Valery's proposal[3] of shell to C
conversion of submodule related codes. What do you all think?
If it does interfere, then can we both work out on something common?


[1]: https://public-inbox.org/git/20170313065148.10707-1-pc44800@xxxxxxxxx/T/#u
[2]: https://public-inbox.org/git/CAGZ79kYW1zS3-9AYPaiUfBGTFygyg1ZVd3YyOctp3gihfEpHeg@xxxxxxxxxxxxxx/T/#u
[3]: https://public-inbox.org/git/20170310211348.18887-1-me@xxxxxxxxxxxx/T/#u