On Mon, Sep 21, 2020 at 9:52 AM Christian Couder <christian.couder@xxxxxxxxx> wrote: > > On Sun, Sep 20, 2020 at 6:31 PM Kaartic Sivaraam > <kaartic.sivaraam@xxxxxxxxx> wrote: > > > > On 07-09-2020 00:26, Kaartic Sivaraam wrote:> > > >> I would appreciate help to find project ideas though. Are there still > > >> scripts that are worth converting to C (excluding git-bisect.sh and > > >> git-submodule.sh that are still worked on)? > > > > > > I think Dscho's e-mail linked below gives a nice overview of the various > > > scripts and their likely status as of Jan2020: > > > > > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@xxxxxxxxxxxxxxxxx/ > > > > > > I'm guessing only the status of submodule has changed as it's being > > > worked on now. > > > > After giving it a second thought, I believe I should take back my word > > about the git-submodule status changing. There still seems to be some > > work left for it. > > Yeah, there is some work left, but Shourya said he was interested in > continuing to work on it. Yeah, I am a bit busy right now catching up with the classes and assignments in my college. I will try to deliver a follow-up v2 to 'submodule add' in a couple of weeks. > > To be clear, > > > > - there's 'add', whose conversion is currently stalled [1] > > Yeah, but it hasn't been stalled for a long time, and sometimes it > takes time after the GSoC or Outreachy period for former GSoC students > or Outreachy interns to resume their work. > > > - there's 'update', which still has a decent amount of code [2] > > in the shell script. > > - we still have to complete the conversion completely converting > > moving the rest of the bits from `git-submodule.sh` to C which is > > mostly just the option parsing. This might be more trickier than > > it sounds as we would've to ensure the we don't accidentally > > change behaviour of the options when moving the option parsing to C. > > > > There's also an e-mail from Junio which is relevant [3] > > > > I'm not sure if this would be enough for a complete project on it's own. > > I'm also not sure whether 'add' would get converted in the meantime. In > > any case, I believe we could add a few other small refactoring projects > > to make up for the rest of the period. For instance, > > > > - Replace more instances of `the_index` and `the_repository` > > (https://github.com/gitgitgadget/git/issues/379) > > > > - Turn the `fetch_if_missing` global into a field of `struct repository` > > (https://github.com/gitgitgadget/git/issues/251) > > > > - Possibly others from #leftoverbits > > > > Thoughts? > > Yeah, without 'add' we would have enough related issues for another > project. I would prefer though that we wait for at least 3 months > without any progress before suggesting them as a project. That's what > we usually do and I think it's the right thing to do. If we are talking about submodules, then one project can be to improve the parsing of 'submodule--helper.c' and try to eliminate the shell scripting for this purpose. Another thing which can be done is to clean up the helper sub-commands which were created to aid the conversion (iff they are of little to no use now). I do not have an exact idea if the "improve parsing" and conversion of a couple of subcommands* will be a project big enough for Outreachy or not though. *'submodule update' is a bit messed up right now and will need a solid conversion to C since some of its fragments are there in the C code while some aren't. Also, the shell code of this subcommand is still there meaning that the fragments do not play any direct role in the functioning of the subcommand. I can pass on the conversion of 'update' to Outreachy if the addition of this will amount to a complete project for a potential Outreachy intern. Regards, Shourya Shukla
