mbox series

[GSoC,v2,0/9] submodule: convert the rest of 'add' to C

Message ID 20210805074054.29916-1-raykar.ath@gmail.com (mailing list archive)
Headers show
Series submodule: convert the rest of 'add' to C | expand

Message

Atharva Raykar Aug. 5, 2021, 7:40 a.m. UTC
I missed the adding the first patch of this series, so I am re-sending with the
missing commit included.

No change since v1, except for the inclusion of 75edf24186 (submodule--helper:
add options for compute_submodule_clone_url(), 2021-07-06) at the beginning.

I am including the cover letter of v1 as-is, so the discussion can start from
here, with minor edits to reflect the accurate counts of the patches:

---8<------8<------8<------8<------8<---

NOTE: This series uses the change introduced by 'ar/submodule-add-config'[1]

This series completes the conversion of all the important shell logic in
'submodule add' to C, by wrapping it in a submodule--helper builtin subcommand
called 'add'.

The first 5 patches are preparatory patches. The refactors mostly involve
exposing interfaces to C that were only previously usable as shell subcommands.

Then we have a patch that translates the shell code to C, faithfully reproducing
the behaviour before the conversion.

The last 3 patches are cleanup patches. Our conversions have introduced a lot of
dead code, all of them being 'submodule--helper' subcommands that have no
further use, as we have C interfaces for these already. We remove these
subcommands.

A question about the cache API used in [PATCH 5/9]:
  What is the difference between 'read_cache()' and 'read_cache_preload()'? [2]
  Which one is more appropriate for use in 'die_on_index_match()'?

Fetch-it-Via:
git fetch https://github.com/tfidfwastaken/git submodule-helper-add-list-1

Footnotes
=========

[1] https://lore.kernel.org/git/20210801063352.50813-1-raykar.ath@gmail.com/
[2] More about this question has been detailed in this section of my blog:
http://atharvaraykar.me/gitnotes/week5#some-challenges-with-the-changes-that-are-cooking

I'll quote it here for convenience:

> Before iterating through the cache entries of the index, you need to populate
> it.
>
> There’s two functions for this: read_cache() and read_cache_preload(). I have
> used the latter in my code. The thing is, when I swap it with the former, I
> could not find any change in the behaviour of my code. They appear to function
> equivalently.
>
> I understand that the *_preload() variant takes a pathspec which preloads index
> contents that match the pathspec in parallel. I don’t know what passing NULL to
> it does. Moreover, does this imply that read_cache() loads the cache on-demand,
> ie, it does no preloading?
>
> I am not sure about what exactly are their differences, and when is one variant
> preferred over the other.

--->8------>8------>8------>8------>8---

Atharva Raykar (9):
  submodule--helper: add options for compute_submodule_clone_url()
  submodule--helper: refactor resolve_relative_url() helper
  submodule--helper: remove repeated code in sync_submodule()
  dir: libify and export helper functions from clone.c
  submodule--helper: remove constness of sm_path
  submodule--helper: convert the bulk of cmd_add() to C
  submodule--helper: remove add-clone subcommand
  submodule--helper: remove add-config subcommand
  submodule--helper: remove resolve-relative-url subcommand

 builtin/clone.c             | 118 +-------------
 builtin/submodule--helper.c | 304 +++++++++++++++++++-----------------
 dir.c                       | 114 ++++++++++++++
 dir.h                       |   3 +
 git-submodule.sh            |  96 +-----------
 5 files changed, 280 insertions(+), 355 deletions(-)