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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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

> * 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/