git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: js/scalar, was Re: What's cooking in git.git (Oct 2021, #05; Mon, 18)
Date: Wed, 20 Oct 2021 15:42:20 +0200	[thread overview]
Message-ID: <211020.86zgr3n698.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2110191436250.56@tvgsbejvaqbjf.bet>


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@evledraar.gmail.com/
2. https://lore.kernel.org/git/nycvar.QRO.7.76.6.2110201349570.56@tvgsbejvaqbjf.bet/

  reply	other threads:[~2021-10-20 14:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-19  6:48 What's cooking in git.git (Oct 2021, #05; Mon, 18) Junio C Hamano
2021-10-19 12:45 ` js/scalar, was " Johannes Schindelin
2021-10-20 13:42   ` Ævar Arnfjörð Bjarmason [this message]
2021-10-21  8:33     ` Johannes Schindelin
2021-10-22 13:43       ` Ævar Arnfjörð Bjarmason
2021-10-22 15:55         ` Johannes Schindelin
2021-10-26 12:20           ` Ævar Arnfjörð Bjarmason
2021-10-27 23:56             ` Junio C Hamano
2021-10-19 19:33 ` Johannes Sixt
2021-10-19 22:49 ` Glen Choo
2021-10-20 11:37 ` ab/config-based-hooks-2 Ævar Arnfjörð Bjarmason
2021-10-21 11:32 ` ab/only-single-progress-at-once (was: What's cooking in git.git (Oct 2021, #05; Mon, 18)) Ævar Arnfjörð Bjarmason
2021-10-27 19:26 ` What's cooking in git.git (Oct 2021, #05; Mon, 18) Emily Shaffer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=211020.86zgr3n698.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).