I am no git expert, so this could be completely off. But as far as I understand it, git submodules (https://git-scm.com/book/en/v2/Git-Tools-Submodules <https://git-scm.com/book/en/v2/Git-Tools-Submodules>) are exactly for this purpose.
From their description: It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other. Here’s an example. Suppose you’re developing a website and creating Atom feeds. Instead of writing your own Atom-generating code, you decide to use a library. You’re likely to have to either include this code from a shared library like a CPAN install or Ruby gem, or copy the source code into your own project tree. The issue with including the library is that it’s difficult to customize the library in any way and often more difficult to deploy it, because you need to make sure every client has that library available. The issue with copying the code into your own project is that any custom changes you make are difficult to merge when upstream changes become available. Git addresses this issue using submodules. Submodules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate. The different add-ons could be added as submodules, so they would be in separate repos, you don’t have to download all if you are only working on one, the core team can exclude them easily if they do not work anymore from the general build process (and re-add them as easy), Are treated, when complaint (as mentioned the windows binaries) as one single repo. Developers of add-ons do not need write access to the core repo Here is another link to the GitHub blog on how they can be used: https://github.blog/2016-02-01-working-with-submodules/ <https://github.blog/2016-02-01-working-with-submodules/> Cheers, Rainer > On 25 May 2019, at 17:04, Markus Neteler <nete...@osgeo.org> wrote: > > On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath > <stefan.blumentr...@nina.no> wrote: >> >> Hi, >> >> Collecting addons in a central repo seems very valuable to me too, for all >> the reasons Vacslav mentioned. > > +1 > >> I am no git expert either, but PRs should not be a big issue to do (unless >> you are VERY productive). People could merge their own PRs, no? > > Exactly. > >> Creating a PR, does not mean it has to be reviewed by another dev, right? In >> my organization colleagues even usr PRs for repos where they are the only >> contributor... > > I also prefer PRs. At least the changes have a chance to be reviewed > and appear more traceable. > >> I would argue having procedures as equal as possible between addons and core >> is just beneficial. Less confusion, fewer guidelines to maimtain, >> possibility to have CI before things are merged, and training for new devs >> that evolve from addon-dev to core-dev... > > +1^2 > > Cheers, > Markus > _______________________________________________ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Orcid ID: 0000-0002-7490-0066 Department of Evolutionary Biology and Environmental Studies University of Zürich Office Y34-J-74 Winterthurerstrasse 190 8075 Zürich Switzerland Office: +41 (0)44 635 47 64 Cell: +41 (0)78 630 66 57 email: rainer.k...@uzh.ch rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
