Re: [PATCH v3 00/15] [RFC] Upstreaming the Scalar command
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Sep 13, 2021, 20:53 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2109131914080.55@tvgsbejvaqbjf.bet>
- In-Reply-To
- <87ilz44kdk.fsf@evledraar.gmail.com>
Hi Ævar,
On Mon, 13 Sep 2021, Ævar Arnfjörð Bjarmason wrote:
Show 34 quoted lines
> > On Thu, Sep 09 2021, Ævar Arnfjörð Bjarmason wrote: > > > On Wed, Sep 08 2021, Johannes Schindelin via GitGitGadget wrote: > > > >> Changes since v2: > >> > >> * Adjusted the description of the list command in the manual page , as > >> suggested by Bagas. > >> * Addressed two style nits in cmd_run(). > >> * The documentation of git reconfigure -a was improved. > >> > >> Changes since v1: > >> > >> * A couple typos were fixed > >> * The code parsing the output of ls-remote was made more readable > >> * The indentation used in scalar.txt now consistently uses tabs > >> * We no longer hard-code core.bare = false when registering with Scalar > > > > In the summary I had on v1->v2 points 1-3 are for v2->v3, respectively, > > outstanding, addressed, outstanding: > > > > https://lore.kernel.org/git/877dfupl7o.fsf@evledraar.gmail.com/ > > > > In addition the discussion ending here: > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2109082112270.55@tvgsbejvaqbjf.bet/ > > > > For that point: I think it's fair enough not to properly handle the > > cleanup case in "scalar clone", but perhaps add a note in the commit > > message that unlike "git clone" this is known not to clean after itself > > properly on ctrl+c? > > Seeing [1] about the planned re-roll I have the above a shot a few days > ago, see the original discussion at [2] (indirectly linked above).
There is a good reason why I did not engage in that tangent about deviating from the established `contrib/*/Makefile` paradigm: I find it particularly unrelated to what this here patch series is trying to accomplish, and I cannot bring myself to be interested in the proposed build system changes, either, because I do not see any benefit in the changes, only downsides.
I find the distraction unnecessary.
Besides, the way I designed it, the code in `contrib/scalar/` intrudes as little as possible on the core Git build system. The impact on the top-level `Makefile` is quite minimal, which is just the way I firmly believe it should be.
In short: I do not want those intrusive changes to the top-level `Makefile`, not in this patch series, and not as a follow-up, either.
We have much bigger fries to fry: namely, how to migrate the improvements for large-scale operations from Scalar to core Git, so that all Git users can benefit. Granted, it will take a lot effort, and it would be easier to move around `Makefile` rules instead. But ultimately, the benefit of allowing users to handle larger repositories with ease will be worth that effort.
Ciao, Johannes