Hi Ævar,

tl;dr it isn't worth your nor my time for you to focus on the build
process in contrib/scalar/ at this moment.

Having said that, I do appreciate your interest in this patch series, and
I have suggestions at the end of this mail how we could collaborate on it
in a more fruitful manner.

On Wed, 20 Oct 2021, Ævar Arnfjörð Bjarmason wrote:

> 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.

Right. They are just a start.

I would like to direct your attention to
https://github.com/microsoft/git/compare/vfs-2.33.0...dscho:vfs-with-scalar,
which has a more complete picture of what I have.

It is a thicket of 8 patch series. I would like to hold your horses until
it is time for me to submit `include-scalar-in-build`, in particular
https://github.com/dscho/git/commit/473ca8ae673.

> 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.

Scalar is headed to contrib/ _specifically_ to make it clear that it is
_not_ a core part of Git. I laid out the reasons before: the user
interface of the Scalar executable is already in use, and hence
non-negotiable.

Since it won't be part of core Git, I fail to see the urgency to integrate
its build process more closely into Git's build process, _right now_.

> 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.

The link I was implying was
https://github.com/microsoft/git/blob/HEAD/contrib/scalar/docs/index.md.
Sorry for not spelling it out clearly.

> 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.

One of the many reasons why one might want to accrue technical debt, and
it is my reason in this context, is the expectation that it won't need to
be paid down at all because we will eventually just delete contrib/scalar/
in a couple of years, when it has served its purpose.

> 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.

Unfortunately, it is very much a distraction of my efforts. Not only would
your patches force me to spend more time to rework and adapt my patches to
your changes, as they _specifically_ touch the same code that I am working
on. It is also forcing me to spend time on reading all your mails, and on
writing mails like this one.

I would have much rather spent my energy on the next steps: contributing
the `scalar-diagnose` patches, and working towards a new, experimental
`git clone`/`git init` option that automatically registers the worktree
with `git maintenance`, and then using that in `contrib/scalar/`.

It would be helpful to pick up other feature enhancements, in less related
code locations (to avoid stepping on each others' toes all the time), such
as silencing the warning in `scalar reconfigure -a` when an enlistment was
deleted manually, and instead removing it from the `scalar` and the
`maintenance` sections in `~/.gitconfig`. Or to teach `git maintenance` to
already do the equivalent when a scheduled run detects a missing worktree.

Ciao,
Dscho