Submodules *are* already used as I said previously or would be obvious to anyone reading the code. I'd recommend doing the latter before posting.
Anyway I'm not replying to this thread anymore since it's obvious we are getting to the point of diminishing returns. If you have improvements please submit short pull requests via github -- a good example of the sort of thing which is useful is https://github.com/rakudo/star/commit/9c2f2b51a9a078ea34d4cbeb7122196948d05d48 Short, simple non-controversial pull requests stand the greatest chance of being merged. In most cases you will need to run the code successfully to confirm it works. An example of what isn't useful is a long self indulgent wordy rant about how no one else understands security but yourself. Most people will start ignoring this sort of thing after a while if they haven't already. Cheers Steve On 29 July 2017 at 04:29, R0b0t1 <r03...@gmail.com> wrote: > On Fri, Jul 28, 2017 at 10:20 PM, R0b0t1 <r03...@gmail.com> wrote: >> Hello, >> >> I apologize for the very long message. Yes, replies to three people >> are in there. The responses were appreciated and I have replied to >> them where replies were warranted. >> >> >> On Fri, Jul 28, 2017 at 2:39 AM, Joachim Durchholz <j...@durchholz.org> >> wrote: >>> Am 28.07.2017 um 04:35 schrieb R0b0t1: >>>>> >>>>> The earliest versions of the Rakudo Star build system started out by >>>>> trying to use Git submodules to manage packages, but it quickly proved to >>>>> be >>>>> unwieldy and almost impossible to understand and maintain. Perhaps the >>>>> submodule ecosystem has changed since then, though. >>>> >>>> >>>> Can you give an example of how submodules were insufficient? >>> >>> >>> I don't know what was unwieldy for the Perl6 guys, but having to manage >>> multiple repositories for a given task is always some extra steps when >>> synchronizing new code to the public repositories. If one of those steps is >>> forgotten, everybody will see repositories that won't work, or show weird >>> problems. >>> >>> Submodules are built for the use case that repositories evolve independently >>> of each other, subtrees for the case that they evolve in sync. It's possible >>> that submodules were the wrong approach, or that subtrees didn't work well >>> enough at the point in time, or that nobody found the time to set everything >>> up well enough to make it really work, or for lack of knowledge how to get >>> submodules to work well. >>> Since everybody's time is constrained, and Perl6 is still a work in >>> progress, there is a long list of things that could be improved, so it's no >>> surprise to see defects. The more important question is whether defects are >>> important. >>> >> >> That is a decent enough explanation. If anyone can chime in with >> specifics I am still interested, as I don't see how learning the dance >> for submodules is any different than learning the dance for Git in >> general. That explanation makes sense if submodules were investigated >> before being used in depth, but >> > > Whoops. > > That explanation makes sense if submodules were investigated before > being used in depth, but someone already commented and said that they > were being used but were abandoned. > > R0b0t1. -- 4096R/EA75174B Steve Mynott <steve.myn...@gmail.com>
