Mistakes in the stalled category? (Was: Re: What's cooking in git.git (Jan 2022, #03; Thu, 13))

[Elijah Newren <newren@gmail.com>]

Hi,

Are there some errors with the stalled category this time around?  In
particular...

On Fri, Jan 14, 2022 at 7:16 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> --------------------------------------------------
> [Stalled]
>
> * ds/sparse-checkout-requires-per-worktree-config (2021-12-21) 5 commits
>  . sparse-checkout: use repo_config_set_worktree_gently()
>  . config: add repo_config_set_worktree_gently()
>  . worktree: add upgrade_to_worktree_config()
>  . config: make some helpers repo-aware
>  . setup: use a repository when upgrading format
>
>  "git sparse-checkout" wants to work with per-worktree configration,
>  but did not work well in a worktree attached to a bare repository.
>  source: <pull.1101.v2.git.1640114048.gitgitgadget@gmail.com>

It has been two weeks since the last submission and emails about this
topic, so maybe you put this one in "stalled" intentionally.  (If so,
and Stolee if this really is stalled, would you like me to try
updating?  I know it has expanded quite a bit from the early simple
fix you were trying to provide, but you've got most the code I think
you need and some important fixes I wouldn't want to see dropped.)
But I'm wondering if marking this topic as stalled was intentional,
because:

> * pw/add-p-hunk-split-fix (2022-01-12) 2 commits
>  - builtin add -p: fix hunk splitting
>  - t3701: clean up hunk splitting tests
>
>  "git add -p" rewritten in C regressed hunk splitting in some cases,
>  which has been corrected.
>
>  Will merge to 'next'?
>  source: <pull.1100.v2.git.1641899530.gitgitgadget@gmail.com>
>
>
> * gc/fetch-negotiate-only-early-return (2022-01-12) 3 commits
>  - fetch --negotiate-only: do not update submodules
>  - fetch: skip tasks related to fetching objects
>  - fetch: use goto cleanup in cmd_fetch()
>
>  "git fetch --nogotiate-only" is an internal command used by "git
>  push" to figure out which part of our history is missing from the
>  other side.  It should never recurse into submodules even when
>  fetch.recursesubmodules configuration variable is set, nor it
>  should trigger "gc".  The code has been tightened up to ensure it
>  only does common ancestry discovery and nothing else.
>
>  Almost there.
>  source: <20220113004501.78822-1-chooglen@google.com>

These last two series were submitted in the two days; they don't seem
stalled to me.

(The other series in "stalled" besides these three all seemed to
belong there to me.)