On Tue, Sep 14 2021, Johannes Schindelin wrote: > Hi Ævar, > > On Tue, 14 Sep 2021, Ævar Arnfjörð Bjarmason wrote: > >> On Mon, Sep 13 2021, Johannes Schindelin wrote: >> >> > On Mon, 13 Sep 2021, Ævar Arnfjörð Bjarmason wrote: >> > >> >> On Thu, Sep 09 2021, Ævar Arnfjörð Bjarmason wrote: >> >> >> >> > 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@xxxxxxxxxxxxxxxxxxx/ >> >> > >> >> > In addition the discussion ending here: >> >> > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2109082112270.55@xxxxxxxxxxxxxxxxx/ >> >> > >> >> > 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. >> >> Perhaps I'm reading too much between the lines here, so forgive any >> undue knee-jerk reaction. > > Okay, let's try an analogy. > > Imagine that a person is asking for directions to the train station. And > the other person is replying by asking "did you know that this train > station was built in 1878? It is actually quite interesting a story... > [and then goes on to describe the history and what excites them about > it]". Now, the first person tries again to ask for directions, again does > not get an answer to that question, and is slowly starting to look at > their watch. The second person, being completely oblivious to all of this, > goes on with their wonderful story about the train station and its > cultural heritage. So the first person walks a bit further to ask a third > person, but the second person is not done yet and says "but you haven't > heard me out! That's disrespectful!". To be clear that's not what I said or meant. I wasn't saying you had to exhaustively hear out some argument or participate in a discussion you're not interested in. I am saying that if you're soliciting feedback and you get some, and the person giving you the feedback sends you pings back, as I did here: https://lore.kernel.org/git/871r6axban.fsf@xxxxxxxxxxxxxxxxxxx/ https://lore.kernel.org/git/87mtoxwt63.fsf@xxxxxxxxxxxxxxxxxxx/ https://lore.kernel.org/git/877dfupl7o.fsf@xxxxxxxxxxxxxxxxxxx/ https://lore.kernel.org/git/87r1dydp4m.fsf@xxxxxxxxxxxxxxxxxxx/ That it would be nice to at least reply with some brief comment to the effect that you're not personally interested in improving this area. Now, shortly after you send this you re-rolled the v3 (https://lore.kernel.org/git/pull.1005.v4.git.1631630356.gitgitgadget@xxxxxxxxx/) with a note of: * Removed the [RFC] prefix because I did not hear any objections against putting this into contrib/. I don't know if you wrote that after this reply, or really didn't see any of above, but that's a really inaccurate/misleading comment considering that context. > Just imagine for a minute how you would feel if you were the first person. > > And that is how I feel asking for reviews about the Scalar patch series > and then being forcefully dragged into that tangent about the build > process. > > I find the well-established paradigm to keep contrib/'s build procedures > as confined to their own directory as possible the most reasonable way to > handle the build by virtue of _not_ polluting the top-level Makefile > unnecessarily. All of your objections strike me simply as personal > viewpoints, not as technical arguments, and they fail to address this > "pollution of the top-level Makefile" problem. I therefore strongly > disagree with your suggestion that the build system should be changed, I > would even argue that your suggestion should been dismissed on purely > technical grounds, and I wish you hadn't forced me to say this as > forcefully. > > And even if I looked more favorably on your suggestion to change the build > procedure, I find this distraction about the build as little constructive > as the explanations about the train station's history above. If we're indulging each other, here's my version of that train analogy: We're in the business of selling a sugary drink that comes in a red can. We've got a big factory with an attached train station, and all the trains that move our product are also red. Now, some of our customers want the new purple colored sugary drink we've cooked up. A new purple factory's all set up for making them. But for some reason the part of the business and distribution plans call for building a new purple train station parallel to our existing one. All purple sugary drinks are expected to be moved on purple trains, all our conductors will need some slight re-training and switchover time to flip-flop between red and purple trains. Issues with purple production floors and purple workflows will need to be ironed out. We did a survey of our customers and most of them weren't even aware that there was such a thing as train. Or perhaps they've seen other trains, but most haven't seen our trains. Trains occasionally need field servicing, luckily our fleet of red trains is set up to carry its own spare parts. Purple trains can only be serviced with the assistance of a red train. A product survey asking customers whether their enjoyment of the red or purple sugary drinks might be impacted by the color of the train they were shipped on only resulted in puzzled blank looks from the participants. The current state of the purple train station and its fleet of purple trains is that it somewhat works with some hiccups. The currently built purple train station omitted any sort of train track for leaving the station though. It should be easy to add one, but... The manager of the purple train project has been asked whether we can't just have our red machines in our red factory make the purple sugary drink, which we can then load on our fleet of red trains. Why do we need a new parallel rail system when we really care about customers drinking our delicious sugary drinks? In case it's not obvious: {red,purple} sugary drink = /usr/bin/git & /usr/bin/scalar {red,purple} train station = ./Makefile & ./contrib/scalar/Makefile train track for leaving the station = make install (AFAICT your current patches have no installation mechanism) > Those > suggestions do succeed in derailing the conversation about how Git could > scale better, how Scalar _does_ teach Git how to scale better, and about > how to teach Git itself more and more of Scalar's tricks. > > If you have ideas how to teach, say, `git clone` to perform a couple of > Scalar's tricks, by all means, let's hear them, or even better, let's see > those patches. If you want to change the build system, still, I cannot > stop you from sending patches to that end to the Git mailing list, but > please expect me to be uninterested in them in any way, and to prefer to > spend my efforts to improve Git elsewhere. If you have other ideas how to > improve on Scalar in a user-perceptible way, however, I am all ears again. > > I hope this clarifies it, without the need to read between the lines, > Johannes Whatever the end goal of the patches you're sending part of them is proposing a given approach to go from A to B. I find it odd to be claiming that the end-state is so important that we can't spare time to discuss some of the implementation details. Particularly in this case, where I've sent a mostly working patch-on-top which I think should be clear from context I'd be willing to finish up, so it's not like it's just pointless nitpicking with no end-goal of a code improvement in sight.
