From: Atharva Raykar <raykar.ath@gmail.com>
To: git@vger.kernel.org
Cc: Christian Couder <christian.couder@gmail.com>,
Shourya Shukla <periperidip@gmail.com>,
Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
Subject: [GSoC] My Git Dev Blog - Week 13
Date: Fri, 13 Aug 2021 18:18:03 +0530 [thread overview]
Message-ID: <m2im09a4dl.fsf@gmail.com> (raw)
Here's the link to the blog: <https://atharvaraykar.me/gitnotes/week13>
Since it's a short one, I'll share the text here as well:
1 Week 13: Preparing for the wrap up
====================================
2 Project Progress
==================
This week's update will be relatively short, partly because I will be out of
town and juggling multiple things this week, and also because I am saving up for
the larger final report ;-)
This week I re-rolled my [run-update-procedure] patch. I was tempted to also send
out my series that [converts the rest of submodule update] to C, but it is quite a
big series, and it doesn't help that we are already at the release week for Git.
I felt I should be a little more patient, and wait for `run-update-procedure` to
get picked up first rather than send a storm of all these related series at
once, at a time of release rush.
In other news, my attempt to making `submodule` a fully C builtin is shaping up
well. Here's a brief of how the transition will work:
- We have a switch called `submodule.useBuiltin` (as well as
`GIT_TEST_SUBMODULE_USE_BUILTIN` as an environment variable for the test
suite) which defaults to false. When set to true, we use the builtins that are
purely in C.
- If the switch is set to true, but the user requests a command that has not been
converted yet, it falls back to using the old shell starting point. This
allows us to test the newly ported builtins with the switch set to true, while
still passing the test suite as a whole.
I expect this transition to be rather brief, because the commands are already
implemented, all we need to do is manage the flag parsing. As of now [I have
already ported the `submodule status` command] to a pure C builtin. I am open to
taking comments on this approach, feel free to leave them on the GitHub web
interface, or on the list.
------------------------------------------------------------------------
Have a great weekend!
---
Atharva Raykar
ಅಥರ್ವ ರಾಯ್ಕರ್
अथर्व रायकर
[run-update-procedure] <https://lore.kernel.org/git/20210813075653.56817-1-raykar.ath@gmail.com/>
[converts the rest of submodule update] <https://github.com/tfidfwastaken/git/tree/submodule-update-list-1>
[I have
already ported the `submodule status` command] <https://github.com/tfidfwastaken/git/commits/submodule-make-builtin-2>
next reply other threads:[~2021-08-13 12:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 12:48 Atharva Raykar [this message]
2021-08-14 7:09 ` [GSoC] My Git Dev Blog - Week 13 Christian Couder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m2im09a4dl.fsf@gmail.com \
--to=raykar.ath@gmail.com \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
--cc=kaartic.sivaraam@gmail.com \
--cc=periperidip@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).