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@xxxxxxxxx/ 2. https://lore.kernel.org/git/b67bbef4-e4c3-b6a7-1c7f-7d405902ef8b@xxxxxxxxx/
