Hi Junio, On Mon, 18 Oct 2021, Junio C Hamano wrote: > * js/scalar (2021-10-07) 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? As far as I am concerned, the current status is: We agreed that this thing _can_ live in contrib/, and that the `scalar` command itself should not be integrated deeply into Git because the end game is for `git clone` (and maybe `git maintenance`) to learn Scalar's tricks. A concern was raised that `make -C contrib/scalar` does not rebuild `libgit.a` whenever any of `libgit.a`'s source files were modified. In light of the previous paragraph, I believe that my time would be better spent on designing a new `git clone` option, though, than to spend time on a build process that will be soon obsolete (except if I allow myself to be distracted by things like teaching `make -C contrib/scalar` to know about `libgit.a`'s prerequisites). In other words, it is a technical debt I firmly believe is worth accruing. Other than that, I heard no objections, therefore I believe that this is ready for `next`, to be cooked in the v2.34 cycle. Ciao, Dscho
