On Tue, Oct 19 2021, Johannes Schindelin wrote:
> 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.
Your patches as they stand don't implement a "make install{-doc,-man}"
for the new command. I have a WIP patch on top to make that and various
other things that are broken about it work as summarized in[1].
I'm happy to help you make that work, but I don't think framing it as
some abstract objection about whether something lives in contrib or not
is accurate.
I'v said that I don't care how things live in-tree in the abstract, but
as a practical matter much of our build process is entangled with what
lives at which paths. That issue with having an incomplete libgit.a
dependency graph is just the tip of the iceberg.
For example in your just-sent[2] you say:
I would like to add a plug for Scalar here. Maybe we can link to this
"opinionated tool based on Git" here? I wouldn't ask if I didn't _know_
that it helps monorepo users out there.
I agree that would be useful, but currently our documentation build
would fail if you linked to the scalar from other git documentation.
Since we lint it and check if the linkgit:* crosslinks would be 404'd.
That's aside from the issue of there being no installation targets in
your version of the Makefile integration, so even if you get that past
the "lint" the installed docs wouldn't have a scalar documentation
installed on the system.
Of course all of those issue are fixable if your version of the patches
were to land, as are other issues like your new *.c file implicitly not
being covered by the coccicheck target.
I don't see why wouldn't consider an up-front solution to that technical
debt, or why you're seemingly ignoring comments about aspects of your
patches that are broken or will cause that unnecessary technical debt.
It would be a hassle to deal with when it comes to various build-system
integration we already have, or which I have WIP work to implement. I'm
also offering to fix it for you, so it wouldn't be much of a distraction
to your efforts.
1. https://lore.kernel.org/git/87fstdgh8m.fsf@xxxxxxxxxxxxxxxxxxx/
2. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2110201349570.56@xxxxxxxxxxxxxxxxx/
