js/scalar (was: What's cooking in git.git (Oct 2021, #07; Fri, 29))

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 1, 2021, 19:34 UTC
Message-ID: <211101.86k0hr3bss.gmgdl@evledraar.gmail.com>
In-Reply-To: <xmqqr1c3e57a.fsf@gitster.g>

On Fri, Oct 29 2021, Junio C Hamano wrote:

Show 20 quoted lines

> * js/scalar (2021-10-27) 15 commits
>  - scalar: accept -C and -c options before the subcommand
>  - scalar: implement the `version` command
>  - scalar: implement the `delete` command
>  - scalar: teach 'reconfigure' to optionally handle all registered enlistments
>  - scalar: allow reconfiguring an existing enlistment
>  - scalar: implement the `run` command
>  - scalar: teach 'clone' to support the --single-branch option
>  - scalar: implement the `clone` subcommand
>  - scalar: implement 'scalar list'
>  - scalar: let 'unregister' handle a deleted enlistment directory gracefully
>  - scalar: 'unregister' stops background maintenance
>  - scalar: 'register' sets recommended config and starts maintenance
>  - scalar: create test infrastructure
>  - scalar: start documenting the command
>  - scalar: create a rudimentary executable
>
>  Add pieces from "scalar" to contrib/.
>
>  What's the status of this thing?

I've been noting breakages in the build integration and submitted a patch-on-top[1] as part of the general RFC Derrick Stolee[2] started about how to integrate such components in-tree.

I think it would be helpful if you weighted in on this whole discussion about if/how in-tree path prefixes are meaningful as a method of "marking" certain components or not.

It seems to me that some assumptions in the approaches described in [2] ultimately come down to reading the tea leaves vis-a-vis what patches the maintainer might accept in the future to the discussed components

1. https://lore.kernel.org/git/patch-1.1-86fb8d56307-20211028T185016Z-avarab@gmail.com/
2. https://lore.kernel.org/git/b67bbef4-e4c3-b6a7-1c7f-7d405902ef8b@gmail.com/