GSoC Project | Submodules related work
- Date: Wed, 15 Mar 2017 15:03:56 +0530
- From: Prathamesh Chavan <pc44800@xxxxxxxxx>
- Subject: GSoC Project | Submodules related work
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.
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) 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 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 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?