{"thread":{"id":"55485","subject":"[GSoC] Proposal: Convert Git submodule to built-in","startedAt":"2021-04-13T10:26:54Z","lastAt":"2021-04-13T10:26:54Z","messageCount":1,"participants":["Firmin Martin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"421866","messageId":"87o8eih449.fsf@Inspiron.i-did-not-set--mail-host-address--so-tickle-me","threadId":"55485","inReplyTo":null,"subject":"[GSoC] Proposal: Convert Git submodule to built-in","fromName":"Firmin Martin","fromEmail":"firminmartin24@gmail.com","sentAt":"2021-04-13T10:26:46Z","receivedAt":"2021-04-13T10:26:54Z","isPatch":false,"sender":{"key":"firminmartin24@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20540328?v=4"},"body":"Hi everyone and potential mentors,\n\nI'm Firmin, a master student who plan applying to GSoC this year. You can find\nbelow my proposal \"Convert Git submodule to built-in\". Any thought or\nfeedback are welcomed.\n\nI'm sorry to send my proposal this late, but I was overwhelmed these days.\n\nI highly recommend to read the Google docs version of my proposal as the\ntextual version (converted through pandoc) missed all hyperlinks,\nmarkups and heading levels. \n\n    https://docs.google.com/document/d/1321TC1Nkn-MpjvKv0VigEHRzcMIyOHO6m8dMsw9SCb4/edit?usp=sharing\n\nThanks,\n\nFirmin\n\n==========================================================================\n\nPersonal Details\n\nContact Information\n\n-   Name: Firmin Martin\n\n-   Blog: https://firminmartin.com\n\n-   Current location: Paris, France (UTC+02:00)\n\n-   Availability: fully available starting from mid-April\n\n-   Emails: <<email1>>, <<email2>>\n\n-   Github: firmart\n\n-   StackExchange: firmin-martin\n\nTechnical Background\n\nI am Firmin Martin, a master student in Theoretical Computer Science at\nÉcole Normale Supérieure de Lyon. My interests include mathematical\nlogic (proof theory), formal verification and human-based computation.\n\nMy first ever programming language was C and it remains my favorite so\nfar. As a matter of fact, I was involved years ago in a bioinformatics\nproject at Institut Curie in which my task consisted of, among others,\nrefactoring a large portion (2k+ loc.) of a C MPI codebase and porting a\nsequential Java code into a parallel MPI version. I thus developed, in\nthe meantime, solid debugging skills using Valgrind and GDB.\n\nI also write shell scripts on a regular basis to satisfy my daily needs.\n\nProgramming Environment\n\nI’m on a dual-boot Ubuntu 20.04/Windows 10, but work primarily on\nUbuntu. I use Emacs as my main editor and Vim in the terminal. I use Git\non a daily-basis either through git itself, the CLI utility tig or the\nEmacs package Magit.\n\nOpen Source Contributions\n\nI’m also a partisan of free/libre and open-source softwares, and\ncontribute to them regularly. That being said, my contribution to FLOSS\nprojects is limited to sporadic bug reports and tiny patches/PRs towards\nsoftwares I use everyday. I also open-sourced some Emacs packages I plan\nto include in the package archive in the future. Here is a short list of\nmy contributions to depict my interests.\n\n-   A tiny PR to translate-shell. translate-shell coding-style has\n      strongly inspired me when I wrote a cheat-sheet maker (2k+ loc. of\n      pure awk) as a (now archived) hobby project.\n\n-   Emacs packages\n\n    -   A fix from the maintainer of Emacs Org mode based on a bug I\n          reported\n\n    -   Some packages I wrote: org-glaux, notmuch-notify,\n          org-desc-initial etc.\n\n    -   Some packages I contributed to: vuiet, mpv.el, org-krita etc.\n\nLearning Git’s Design & Development Process\n\nDespite using Git for years, I reached its codebase for the first time\nin mid-March 2021. I started to learn the organization of the source\ncode (built-in vs. non-built-in scripts, subcommands cmd_* and more),\nthe test infrastructure, the internals (through the Git Pro book), etc.\nIt also took me a while to learn the development process of Git: e.g.\nthe release cycle, and peculiarly to figure out how email-based workflow\nworks as I was used to Github’s PR model and prior this time frame,\nthough I subscribed to some mailing lists using this workflow (Org mode,\nnotmuch), I didn’t go further than reporting bugs and suggesting\nworkarounds. During this period, I also had the opportunity to learn how\nto polish and build a patch through some commands/options I never used\nbefore: git rebase -i, git add -p or git pull -r. Navigating through the\ncommits log was also very helpful to apprehend design decisions.\n\nContributions to Git\n\n+----------------------------------------------------------------------+\n| user-manual.txt: assign preface an id and a title                    |\n|                                                                      |\n| Status: next, also see What's cooking in git.git.                    |\n|                                                                      |\n| git/git: fc12b6fdde47cfb5                                            |\n|                                                                      |\n| firmart/git: doc/assign-preface-id-and-title                         |\n|                                                                      |\n| Mailing list: [PATCH v2 0/1][GSoC] user-manual.txt: assign preface   |\n| an id and a title                                                    |\n|                                                                      |\n| Abstract:                                                            |\n|                                                                      |\n|   Fix two warnings causing visible issues in                         |\n|   Documentation/{user-manual.texi, git.info}.                        |\n+----------------------------------------------------------------------+\n\n+----------------------------------------------------------------------+\n| doc: (monospace) apply CodingGuidelines on a large-scale             |\n|                                                                      |\n| Status: WIP                                                          |\n|                                                                      |\n| firmart/git: doc/apply-coding-guidelines                             |\n|                                                                      |\n| Mailing list: [RFC PATCH v1 00/13][GSoC] doc: (monospace) apply      |\n| CodingGuidelines on a large-scale                                    |\n|                                                                      |\n| Abstract:                                                            |\n|                                                                      |\n|   Make the documentation fully compliant regarding monospace font.   |\n|   It involves around 6k lines of changes made through interactive    |\n|   substitutions. It probably needs to be split off in even smaller   |\n|   chunks to be digestible by reviewers.                              |\n+----------------------------------------------------------------------+\n\nProject proposal: Convert submodule to builtin\n\nIntroduction\n\nQuoting from the Pro Git book:\n\n  “Git was initially a toolkit for a version control system rather than\n  a full user-friendly VCS, it has a number of subcommands that do\n  low-level work and were designed to be chained together UNIX-style or\n  called from scripts. These commands are generally referred to as Git’s\n  ‘plumbing’ commands, while the more user-friendly commands are called\n  ‘porcelain’ commands.”\n\nA lot of Git’s “porcelain” commands stem from this idea and were\nconsequently written as shell/Perl scripts composed by Git’s “plumbing”\ncommands and other shell utilities. Over the time, different platforms\nwere targeted to be supported and projects using Git have grown in size.\nPortability and performance became non-negligible topics.\n\nFor instance, Git for Windows relies on a modified version of Cygwin,\ncalled MSYS2, to run those shell scripts. They tend to have\ncompatibility issues due to this requirement (see the next section).\n\nMoreover, even though subshell overheads are relatively cheap, they can\ngrow fastly when involved in a loop or spawn in a nested fashion. The\nsituation is even worse when a high-level porcelain shell command calls\nanother one. Hopefully, since the very beginning, it was a common\npractice to make mature shell commands built-in to avoid this concern.\n\nTo see the evolution of this process, one can easily make the following\ntable indicating the date and the commit of popular commands made\nbuilt-in thanks to git naming consistency. Though some of them are born\nbuilt-in, the majority was first implemented as shell/Perl or even Tcl\nscripts[1].\n\nLegend.\n\n-   <date>: date of the command turning built-in.\n\n-   builtin (<date>): the command is implemented directly as built-in in\n      the given date.\n\n-   ongoing (<patch>): there is an active process to turn the command\n      built-in.\n\n+----------+----------+----------+----------+----------+----------+\n| Command  | Date     | Commit   | Command  | Date     | Commit   |\n+==========+==========+==========+==========+==========+==========+\n| add      | 20       | c6       | mai      | builtin  | 20       |\n|          | 16-05-17 | 99f9b924 | ntenance |          | 57d75038 |\n|          |          |          |          | (202     |          |\n|          |          |          |          | 0-09-17) |          |\n+----------+----------+----------+----------+----------+----------+\n| am       | 20       | 78       | merge    | 20       | 1c       |\n|          | 15-08-04 | 3d7e865e |          | 08-07-07 | 7b76be7d |\n+----------+----------+----------+----------+----------+----------+\n| archive  | builtin  | 4d       | mv       | 20       | 11       |\n|          |          | f096a5ca |          | 06-06-26 | be42a476 |\n|          | (200     |          |          |          |          |\n|          | 6-09-07) |          |          |          |          |\n+----------+----------+----------+----------+----------+----------+\n| bisect   | ongoing  | N/A      | notes    | 20       | cd       |\n|          |          |          |          | 10-02-13 | 067d3bf4 |\n|          | (last    |          |          |          |          |\n|          | patch)   |          |          |          |          |\n+----------+----------+----------+----------+----------+----------+\n| branch   | 20       | c3       | pull     | 20       | b1       |\n|          | 06-10-23 | 1820c26b |          | 15-06-18 | 456605c2 |\n+----------+----------+----------+----------+----------+----------+\n| bundle   | builtin  | 2e       | push     | 20       | ec       |\n|          |          | 0afafebd |          | 06-08-02 | 19a22b74 |\n|          | (200     |          |          |          |          |\n|          | 7-02-22) |          |          |          |          |\n+----------+----------+----------+----------+----------+----------+\n| checkout | 20       | 78       | ra       | builtin  | 34       |\n|          | 08-02-07 | 2c2d65c2 | nge-diff |          | 8ae56cb2 |\n|          |          |          |          | (202     |          |\n|          |          |          |          | 0-09-17) |          |\n+----------+----------+----------+----------+----------+----------+\n| che      | 20       | 95       | rebase   | 20       | d0       |\n| rry-pick | 07-03-01 | 09af686b |          | 19-03-18 | 3ebd411c |\n+----------+----------+----------+----------+----------+----------+\n| clean    | 20       | 11       | reset    | 20       | 0e       |\n|          | 07-11-11 | 3f10f22f |          | 07-09-11 | 5a7faa3a |\n+----------+----------+----------+----------+----------+----------+\n| clone    | 20       | 84       | restore  | builtin  | 46       |\n|          | 08-04-27 | 34c2f1af |          | (201     | e91b663b |\n|          |          |          |          | 9-04-25) |          |\n+----------+----------+----------+----------+----------+----------+\n| commit   | 20       | f5       | revert   | 20       | 95       |\n|          | 07-11-08 | bbc3225c |          | 07-03-01 | 09af686b |\n+----------+----------+----------+----------+----------+----------+\n| describe | 20       | 9a       | rm       | 20       | d9       |\n|          | 07-01-10 | 0eaf83ea |          | 06-05-19 | b814cc97 |\n+----------+----------+----------+----------+----------+----------+\n| diff     | 20       | 8a       | shortlog | 20       | b8       |\n|          | 06-05-01 | b99476ec |          | 06-11-19 | ec59234b |\n+----------+----------+----------+----------+----------+----------+\n| difftool | 20       | 01       | show     | 20       | ba       |\n|          | 17-01-19 | 9678d6b1 |          | 06-04-15 | 1d45051e |\n+----------+----------+----------+----------+----------+----------+\n| fetch    | 20       | b8       | sparse-  | builtin  | 94       |\n|          | 07-09-10 | 88d61c83 | checkout |          | c0956b60 |\n|          |          |          |          | (201     |          |\n|          |          |          |          | 9-11-21) |          |\n+----------+----------+----------+----------+----------+----------+\n| form     | 20       | 68       | stash    | 20       | 40       |\n| at-patch | 06-05-21 | 5637381a |          | 19-02-25 | af146834 |\n+----------+----------+----------+----------+----------+----------+\n| gc       | 20       | 67       | status   | 20       | f5       |\n|          | 07-03-13 | 57ada403 |          | 07-11-08 | bbc3225c |\n+----------+----------+----------+----------+----------+----------+\n| grep     | 20       | 63       | s        | ongoing  | N/A      |\n|          | 06-05-16 | dffdf03d | ubmodule |          |          |\n|          |          |          |          | (last    |          |\n|          |          |          |          | patch)   |          |\n+----------+----------+----------+----------+----------+----------+\n| init     | builtin  | e8       | switch   | builtin  | d7       |\n|          |          | 3c516331 |          |          | 87d311db |\n|          | (200     |          |          | (201     |          |\n|          | 5-04-07) |          |          | 9-03-29) |          |\n+----------+----------+----------+----------+----------+----------+\n| log      | 20       | e3       | tag      | 20       | 62       |\n|          | 06-04-14 | a125a94d |          | 07-07-20 | e09ce998 |\n+----------+----------+----------+----------+----------+----------+\n|          | worktree | builtin  | df       |          |          |\n|          |          |          | 0b6cfbda |          |          |\n|          |          | (201     |          |          |          |\n|          |          | 5-01-29) |          |          |          |\n+----------+----------+----------+----------+----------+----------+\n\nAdditionally, per a mail from Johannes Schindelin, in which he stated\nthe current conversion process of remaining scripts, we can further note\nthe following scripts’ conversion status (with my personal adaptation).\n\n+----------------+----------------+----------------+----------------+\n| Scripts        | Status         | Scripts        | Status         |\n+================+================+================+================+\n| git-difft      | Candidates for | git-fi         | Deprecated     |\n| ool--helper.sh | being          | lter-branch.sh |                |\n|                | converted      |                |                |\n| git-mer        |                | gi             |                |\n| getool--lib.sh |                | t-rebase--pres |                |\n|                |                | erve-merges.sh |                |\n| gi             |                |                |                |\n| t-mergetool.sh |                |                |                |\n|                |                |                |                |\n| git-me         |                |                |                |\n| rge-octopus.sh |                |                |                |\n|                |                |                |                |\n| git-mer        |                |                |                |\n| ge-one-file.sh |                |                |                |\n|                |                |                |                |\n| git-me         |                |                |                |\n| rge-resolve.sh |                |                |                |\n+----------------+----------------+----------------+----------------+\n| git-           | Support for    | g              | Too complex or |\n| quiltimport.sh | legacy[3] SCMs | it-instaweb.sh |                |\n|                |                |                | too many       |\n| git-a          |                | git-r          | dependencies   |\n| rchimport.perl |                | equest-pull.sh |                |\n|                |                |                |                |\n| git-cvsexp     |                | git-           |                |\n| ortcommit.perl |                | web--browse.sh |                |\n|                |                |                |                |\n| git-           |                | git-s          |                |\n| cvsimport.perl |                | end-email.perl |                |\n|                |                |                |                |\n| git-           |                | git-svn.perl   |                |\n| cvsserver.perl |                |                |                |\n|                |                | git-add--in    |                |\n|                |                | teractive.perl |                |\n+----------------+----------------+----------------+----------------+\n\n Summary\n\nThe goal of this GSoC project is to finish the ongoing conversion\n(started in 2015) of the submodule’s commands from shell script into C\nand totally get rid of the file git-submodule.sh. The file\nsubmodule--helper.c will henceforth be renamed to submodule.c. The\nbenefit to doing so is not only performance-wise, but also\ncompatibility-wise. A quote from Johannes Schindelin, the maintainer of\nGit for Windows, could explain this well:\n\n  “Since git submodule is still implemented as a Unix shell script (and\n  traditionally, there have been tons of issues with that due to the\n  need to use a derivative of Cygwin to interpret such scripts) [...]”\n\nPrevious Works\n\n-   During 2015-2019, Stefan Beller has worked on the conversion of the\n      update command, has finished the conversion of the init command\n      and has ported multiple helper functions in C (module_list,\n      resolve_relative_url, update-module-mode etc.). He has also\n      written in C the absorbgitdirs command.\n\n-   Prathamesh Chavan (GSoC 2017) has finished the conversion of the\n      foreach, deinit, sync and status commands and has ported the\n      helper function set_name_rev in C. He has also worked on an early\n      version of the command add on which Shourya Shukla was based\n      later.\n\n-   Shourya Shukla (GSoC 2020) has finished the conversion of set-url\n      and set-branch commands. He also continued and finished Chavan’s\n      work on the summary (patch) command. His patch on the conversion\n      of the add command is currently at version 3, but staled since\n      then.\n\nConversion Status of Submodule’s Subcommands\n\nMost of the submodule’s subcommands (set-branch, set-url, summary,\nstatus, init, deinit, foreach and sync) have only the options left to\nparse. As for absorbgitdirs, it was written fully in C by Stefan Beller\nsince the beginning.\n\nConsequently, the remaining tasks are the conversion of the update and\nadd subcommands which have both 160 loc. involving essentially Git’s\nplumbing, branching plus some basic filtering with sed and grep besides\nthe options left to parse. The conversion of the add subcommand has a\nlong-standing history (see previous works).\n\nCorrespondence Between Submodule’s Shell and C Code\n\nTo better understand how the conversion would work and how the converted\ncode would look, one should examine the components constituting a\nsubmodule’s subcommand in shell and C respectively.\n\n-   A submodule’s subcommand in shell corresponds simply to\n\n    -   An entry point function cmd_<subcommand> (e.g. cmd_add) which\n          handles options parsing, performs business logic with the\n          assistance of helper functions and Git’s plumbing.\n\n    -   Several helper functions such as sanitize_submodule_env which\n          essentially unset all Git’s environment variables of a\n          repository except GIT_CONFIG_PARAMETERS.\n\n-   On the other hand, a submodule’s subcommand in C is more structural.\n      It corresponds to\n\n    -   A “principal” function <subcommand>_submodule (e.g.\n          init_submodule) which performs the essential business logic.\n          It has at least three parameters: path, prefix and flags\n          coming from the subcommand’s entry point (see below).\n\n    -   A facultative callback function <subcommand>_submodule_cb (e.g.\n          init_submodule_cb) serving as an argument of the higher-order\n          function for_each_listed_submodule which applies the callback\n          function on a list of submodules one by one. The callback\n          functions are essentially wrappers of the subcommand’s\n          “principal” function except that they have a uniform signature\n          (precisely, the type each_submodule_fn).\n\n    -   A facultative[4] callback structure <subcommand>_cb (e.g.\n          init_cb), initialized by the macro <SUBCOMMAND>_CB_INIT (e.g.\n          INIT_CB_INIT), storing option values and flags to serve as an\n          argument of for_each_listed_submodule and the callback\n          function. This structure is necessary to keep the uniform\n          signature of the callback function: it packs together some\n          arguments which feed the “principal” function.\n\n    -   An entry point function module_<subcommand>[5] (e.g.\n          module_init) which parses options, handles flags and\n          eventually calls for_each_listed_submodule along with the\n          callback function and structure on a list of submodules.\n\n    -   A registration of the subcommand in the structure commands and\n          indication whether the subcommand supports --super-prefix.\n\n    -   Several helper functions: either subcommand-specific (e.g.\n          print_status is uniquely dedicated to the status subcommand)\n          or with general purpose (e.g. revision name retrieval:\n          compute_rev_name; URL computation: relative_url,\n          chop_last_dir; string manipulation: starts_with_dot_dot_slash\n          etc.)\n\nProposed Timeline\n\nPresent - 17 May: warm-up\n\nWhile waiting for the announcement of the selected student, I would want\nto be more involved in the Git’s development & submission process, as I\nwould be fully available starting from mid-April. This would start by\ndiscussing in the mailing-list some RFCs I have in mind, not necessarily\ndirectly related to submodules (as it is reserved to the selected\nstudent), e.g.\n\n-   Address the “NEEDSWORK” in path.c::normalize_path_copy_len. This can\n      be proved useful in the next phase while dealing with the path\n      normalization (multiple trailing slashes) occurred in cmd_add.\n      This point was discussed in Shourya Shukla last patch's cover\n      letter.\n\n-   Improve git add -p user interface -- fix corrupt patch line number,\n      paginate diff hunks, and change behaviour of SIGINT in the\n      interactive process -- and trying to reproduce an issue I faced,\n      namely “git add -p restarts itself after selecting the last diff\n      hunk” and figure out a solution.\n\n-   See whether there is room for improvement regarding git format-patch\n      --cover-letter which overwrites existing cover-letter having the\n      same name. Could we just replace the diff statistics of the old\n      cover letter, and keep its title and content ? Or alternatively,\n      create a new cover letter whose filename is suffixed by “~” or “_”\n      ? These are the questions that need to be answered.\n\n-   Adding a “subcommand” entry in Git’s glossary. E.g. submodule is a\n      Git’s subcommand, add is a submodule’s subcommand.\n\n-   Finish the work-in-progress patch series which aims to make the\n      documentation fully compliant regarding monospaced font (see\n      Contributions to Git).\n\nMay 17 - June 7: community bonding\n\nI will use this three weeks time frame to familiarize myself with the\ncodebase and make a series of trivials yet useful patches (as depicted\nbelow) to present a slightly polished version to the community in hope\nto obtain feedback in an early stage and not miss out important\nmistakes. In the end, it would help to have a better estimation of the\nschedule with mentors. More concretely, that could be translated as\nfollows.\n\n-   Study the last patch of Shourya Shukla and available routines in\n      submodule.c and builtin/submodule--helper.c.\n\n-   See if there is any portion of code in his patch which could be\n      reused to\n\n-   Port shell helper functions: especially sanitize_submodule_env which\n      appears numerous times, but also its by-products is_tip_reachable\n      and fetch_in_submodule.\n\n-   Port the basic filtering using sane_grep and sed occurring in\n      cmd_add (e.g. path normalization). As stated in the previous\n      section, the function path.c::normalize_path_copy_len once fixed\n      could be proved useful.\n\n-   Find out present issues in his patch (e.g. potential memory leak in\n      string manipulation) and incorporate feedback to the patch.\n\n-   Study and update present tests to cover new code.\n\n-   Port set-branch, set-url, summary, status, init, deinit, foreach and\n      sync options parsing into builtin/submodule--helper.c so that they\n      merely become wrapper of their C counterparts (i.e. exactly the\n      current status of the absorbgitdirs command).\n\n-   Submit the slightly improved version (RFC) of Shourya Shukla's patch\n      incorporating above considerations (split off in multiple commits)\n      along with a summary of the patch status. Having a first round of\n      review in an early stage would help to detect important mistakes\n      requiring to be taken into consideration.\n\n-   Discuss with mentors to rearrange the schedule if necessary.\n\nJune 7 - July 12: porting the add subcommand & mid-term evaluation (5 weeks)\n\nI would want to start tackling the add subcommand as I believe its\nlong-standing conversion was due to its low priority (it was in Chavan\nproposal’s wishlist and in Shukla proposal’s last phase). At this stage,\nbased on the previous phase’s investigation and first round of review,\nit would be clear what pieces are missing.\n\nAlso, as Prathamesh Chavan’s weekly summaries suggest (12th, 13th and\n14th), he took more than two weeks to deal with failed tests as the\ninvocation of the subcommand add is widely present in the tests (137\ninstances[6] among 53 test files[7]). I would expect to spend a fair\namount of time dealing with them too.\n\nJuly 12 - August 2: porting the update subcommand (3 weeks)\n\nAs Philippe Blain pointed out on Github, it would be better to start\nconverting the update command after having acquired enough insight\nregarding git submodules. That is why I place it right after the port of\nthe add command. I allocate 3 weeks to deal with it as it is mainly\nconstituted of business logic involving built-in function calls. This\nbeing said, I will be peculiarly cautious as bugs could emerge\nunexpectedly.\n\nAugust 2 - August 16: buffering phase\n\nThis period will serve as a buffering phase.\n\n-   If everything goes well, the remaining part of git-submodule.sh will\n      be converted at this phase.\n\n-   This stage will also be the time for polishing, testing and\n      debugging. Without being too optimistic and considering past years\n      students' schedules, there would still be bugs lurking around at\n      this phase.\n\n-   If the submit process goes faster than expected, I will use the\n      remaining time to tackle some of the numerous NEEDSWORK in\n      submodule.c (three in total) and builtin/submodule--helper.c (five\n      in total).\n\nWeekly Blogpost \n\nI commit myself to writing a blog post each week on my blog to allow\nmentors and other contributors keep tracking of my progress. I felt that\nShukla’s blog has provided valuable insight at the moment of this\ndocument being written, and according to Shukla’s words, Matheus\nTavares’ blog (GSoC 2019) has in turn somehow inspired him. I hope I\ncould do the same for future GSoC applicants and keep this great\ntradition.\n\nRegarding the Review Process\n\nAs pointed out by Junio C. Hamano, converting a subcommand in a single\npatch makes the review process harder than it should be. I suggest\ngradually converting portions of the shell script into multiple C\ninternal helping commands and commit them separately while keeping the\ncode functionality. Doing so, it would be easier to locate the removed\nshell code and compare it to the converted C code. This is actually what\nStefan Beller has done when converting a part of the update command. In\nthe last patch of Shourya Shukla, once everything is satisfying enough\n(e.g. no memory leak), the commits could be squashed and the helper\nfunctions could be merged if needed.\n\nI also plan to send a weekly summary in the mailing list to present the\nongoing progress and challenge. When things become mature enough, I will\nalso attach the whole patch series to the summary (exactly as Prathamesh\nChavan did from week 5).\n\nEpilogue\n\nI unfortunately started late and did not have the opportunity to\ncontribute to code-related patches being overwhelmed (see contributions\nto Git). But, to be fair, the amount of things I learned during this\nperiod through the mailing list, the commits log, the documentation or\nthe codebase is absolutely stunning.\n\nAs discussed at the beginning of this document, I have the habit of\ncontributing to open source softwares I’m using on a regular basis. It\nseems the bottleneck of contributing to Git was the lack of\nunderstanding on the mail-based workflow, a thing that I happily\novercomed. From now on, I would be able to contribute to more\nopen-source projects I benefit from (e.g. Emacs, Org-mode, notmuch\netc.). And of course, the adventure with Git has just started!\n\nReferences\n\nProposals\n\n-   Johannes Schindelin's description of the project on Git for Windows’\n      issue tracker\n\n-   Shourya Shukla's GSoC 2020 proposal\n\n-   Prathamesh Chavan's GSoC 2017 proposal\n\nFinal Reports\n\n-   Prathamesh Chavan's final report\n\n-   Shourya Shukla's final report\n\nLast Patch Series\n\n-   Stefan Beller's partial port of the subcommand update (including\n      implementation of the helper function update_module_mode)\n\n-   Stefan Beller's port of helper functions: module_list, module_name\n      and module_clone\n\n-   Prathamesh Chavan's port of the status subcommand and introduction\n      of get_submodule_displaypath and for_each_listed_submodule\n\n-   Prathamesh Chavan's port of the foreach subcommand\n\n-   Prathamesh Chavan's port of the sync and deinit subcommand\n\n-   Shourya Shukla's port of the set-branch subcommand\n\n-   Shourya Shukla’s port of the set-url subcommand\n\n-   Shourya Shukla's port on the summary subcommand\n\n-   Shourya Shukla’s last patch on the port of the add subcommand\n\nDocumentations\n\n-   Git Tools - Submodules from the Pro Git book\n\n-   Git’s man pages: gitsubmodules, git-submodule and gitmodules\n\nGSoC Weekly Summary\n\n-   Shourya Shukla's Blog\n\n-   Prathamesh Chavan's weekly summary and patch series\n\n[1] See gitk-git/gitk and git-gui/git-gui.sh\n\n[2] That being said, quilt last release was from 2019.\n\n[3] That being said, quilt last release was from 2019.\n\n[4] Relevant if a callback function is required by the subcommand.\n\n[5] It does basically the same thing as cmd_<git-subcommand> functions\n(e.g. cmd_commit) except that the prefix module_ is a convention\nsuggesting it’s a subcommand of a Git’s subcommand (i.e. in our context\na submodule’s subcommand).\n\n[6] grep -R 'git submodule add' | wc -l\n\n[7] grep -Rl 'git submodule add' | sort | uniq | wc -l\n"}]}