Re: What's cooking in git.git (Sep 2021, #08; Mon, 27)

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 28, 2021, 08:07 UTC
Message-ID: <87ilylxg85.fsf@evledraar.gmail.com>
In-Reply-To: <CABPp-BGuzd_TH57-1RvwJQD5r3S3ZkJcuiPnU8aWee8pgzUBEw@mail.gmail.com>

On Mon, Sep 27 2021, Elijah Newren wrote:

[Aside: I quite liked the method of replying to What's Cooking per-topic in Johannes's replies to https://lore.kernel.org/git/xmqqsfyf5b74.fsf@gitster.g/; I'm never quite sure if I should have one E-Mail with all of my comments on other in-flight work, use existing commentary as a springboard etc. Doing the latter here]

Show 33 quoted lines

>> * js/scalar (2021-09-14) 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/.
>>
>>  Will merge to 'next'?
>
> I feel bad for taking so long to take a look, but I finally responded
> with a few comments.  Mostly, I'm glad it's a contrib thing; a lot of
> the config makes sense to me (even if some of it is 'meh' for my
> repository sizes or setup), but two of the config settings would be
> very objectionable if they were a core git command.  Since it's
> contrib, though, it's probably fine to be very opinionated...and
> perhaps even excessively so.  ;-)
>
> However, since Johannes has been away for a couple weeks, maybe give
> him a chance to return and respond to myself and others (and perhaps
> push any updates that occurred to him while on vacation) before
> merging down?

Since the thread at https://lore.kernel.org/git/87ilz44kdk.fsf@evledraar.gmail.com/ I've been running with an altered version of Johannes's patches that does the Makefile integration differently, per my https://lore.kernel.org/git/87ilz44kdk.fsf@evledraar.gmail.com/.

I've been trickling in some of the Makefile changes that make that easier (still quite possible on top of "master", I just had some cleanups). It builds[1], tests[2], installs[3] and participates in any auxiliary targets like "check-docs", "sparse"[4] (and now my "sparse-incr") etc.

AFAIKT Johannes's version is so far just doing [1] and [2], and just optionally if you "make" in the contrib subdirectory.

Junio seemed positive on that direction in [1][2]. Re your comments in [3]: Right now "scalar" doesn't define any of its own config, but one way out of some of your comments seems to be to do that.

If it's using its own build system in contrib/scalar that'll happen how exactly? We keep the main manpage in contrib/scalar/scalar.txt but have a Documentation/config/scalar.txt? Have "git help --config" grow some optional mode for scalar-specific config? Add a "scalar help-config"?

In case my opinion on it isn't painfully obvious at this point I think the answer for both current & future integration reasons should be to just have its assets & build logic intergrated with existing locations and logic.

1. https://lore.kernel.org/git/xmqqilz32hhr.fsf@gitster.g/
2. https://lore.kernel.org/git/xmqq1r5qzv35.fsf@gitster.g/
3. https://lore.kernel.org/git/CABPp-BG_wupp1o5bBSYOJSvF3eJjf=TbX0RBHqqKuD+3F8s6hw@mail.gmail.com/