Elijah Newren <newren@xxxxxxxxx> writes: > On Thu, Dec 9, 2021 at 10:12 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >> >> >> So, how about doing it this way? This is based on 'master' and does >> >> not cover contrib/scalar, but if we want to go this route, it should >> >> be trivial to do it on top of a merge of ab/ci-updates and js/scalar >> >> into 'master'. Good idea? Terrible idea? Not good enough? >> > >> > With the caveat that I think the greater direction here makes no sense, >> > i.e. scalar didn't need its own build system etc. in the first place, so >> > having hack-upon-hack to fix various integration issues is clearly worse >> > than just having it behave like everything else.... >> >> We decided to start Scalar in contrib/, as it hasn't been proven >> that Scalar is in a good enough shape to deserve to be in this tree, >> and we are giving it a chance by adding it to contrib/ first, hoping >> that it may graduate to the more official status someday [*]. > > Is that the hope? I thought the wish was for it to eventually > "disappear" rather than "graduate", as per the following bits of > Dscho's cover letter: > > """ > The Scalar project was designed to be a self-destructing vehicle...For > example, partial clone, sparse-checkout, and scheduled background > maintenance have already been upstreamed and removed from Scalar > proper...[Adding Scalar to contrib will] make it substantially easier > to experiment with moving functionality from Scalar into core Git. > """ I can go either way, but my impression from Dscho's messages has always been that there is no strong reason to switch existing scalar users to say "git clone <options that give behaviour like scalar>" when their fingers and scripts are used to say "scalar <this>", and a very thin shell may remain in some form in the ideal world.
