[0/2] Fix behavior of worktree config in submodules

Message

Philippe Blain via GitGitGadget May 23, 2023, 11:17 p.m. UTC

About a year ago, discussion on the sparse index integration of 'git grep'
surfaced larger incompatibilities between sparse-checkout and submodules
[1]. This series fixes one of the underlying issues to that incompatibility,
which is that the worktree config of the submodule (where
'core.sparseCheckout', 'core.sparseCheckoutCone', and 'index.sparse' are
set) is not used when operating on the submodule from its super project
(e.g., in a command with '--recurse-submodules').

The outcome of this series is that 'extensions.worktreeConfig' and the
contents of the repository's worktree config are read and applied to (and
only to) the relevant repo when working in a super project/submodule setup.
This alone doesn't fix sparse-checkout/submodule interoperability; the
additional changes needed for that will be submitted in a later series. I'm
also hoping this will help (or at least not hurt) the work to avoid use of
global state in config parsing [2].

Thanks!

 * Victoria

[1]
https://lore.kernel.org/git/[e-mail]/
[2]
https://lore.kernel.org/git/[e-mail]/

Victoria Dye (2):
  config: use gitdir to get worktree config
  repository: move 'repository_format_worktree_config' to repo scope

 builtin/config.c                       |  3 +-
 builtin/worktree.c                     |  2 +-
 config.c                               | 42 ++++++++++++++++++--------
 environment.c                          |  1 -
 environment.h                          |  1 -
 repository.c                           |  1 +
 repository.h                           |  1 +
 setup.c                                | 10 ++++--
 t/t3007-ls-files-recurse-submodules.sh | 34 +++++++++++++++++++++
 worktree.c                             |  4 +--
 10 files changed, 78 insertions(+), 21 deletions(-)


base-commit: 4a714b37029a4b63dbd22f7d7ed81f7a0d693680
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1536%2Fvdye%2Fvdye%2Fsubmodule-worktree-config-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1536/vdye/vdye/submodule-worktree-config-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1536

Comments

Junio C Hamano May 24, 2023, 10:25 a.m. UTC | #1

"Victoria Dye via GitGitGadget" <[e-mail]> writes:

> About a year ago, discussion on the sparse index integration of 'git grep'
> surfaced larger incompatibilities between sparse-checkout and submodules
> [1]. This series fixes one of the underlying issues to that incompatibility,
> which is that the worktree config of the submodule (where
> 'core.sparseCheckout', 'core.sparseCheckoutCone', and 'index.sparse' are
> set) is not used when operating on the submodule from its super project
> (e.g., in a command with '--recurse-submodules').

OK.  So in short, worktreeConfig used to be a singleton, global for
the entire git process, but because "git grep" (and possibly others)
wants to operate across repository boundary when recursing into
submodules, the repository_format_worktree_config needs to be per
repository instance, not a global singleton.

Makes sense.

Glen Choo May 25, 2023, 7:56 p.m. UTC | #2

"Victoria Dye via GitGitGadget" <[e-mail]> writes:

> The outcome of this series is that 'extensions.worktreeConfig' and the
> contents of the repository's worktree config are read and applied to (and
> only to) the relevant repo when working in a super project/submodule setup.

Thanks sending these patches! This is an obvious bug, and squashing
another global is always helpful.

> I'm
> also hoping this will help (or at least not hurt) the work to avoid use of
> global state in config parsing [2].

Both pieces of work touch different bits I think - yours plumbs and
reads a "struct repository" before the config iterating begins, mine
plumbs config source information after the config interating - so
they don't help each other, but at least the conflicts are only textual.

Junio: There are quite a few conflicts. AFAICT each only has to be
resolved once (IOW the number of conflicts to be fixed is the same with
"git merge" vs "git rebase"). I have a v2 that I'm about to send, and if
you'd prefer (especially since you're on half-vacation), I can base it
off Victoria's topic, which looks pretty straightforward and will
probably get merged pretty quickly.