<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 27, 2019 at 3:12 AM Rainer M Krug <<a href="mailto:Rainer@krugs.de">Rainer@krugs.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Disadvantage: From the GitHub blog:<div><br></div><div><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;font-size:16px;color:rgb(36,41,46);font-family:-apple-system,system-ui,"Segoe UI",Helvetica,Arial,sans-serif;font-variant-ligatures:normal;background-color:rgb(255,255,255)"><li style="box-sizing:border-box;margin-top:0.25em">Managing dynamic, rapidly evolving or heavily co-dependent repositories with submodules can quickly become frustrating. This post was focused on simple, relatively static parent-child repository relationships. A future follow-up post will detail some strategies to help manage more complex submodule workflows.</li></ul><div><div>Probably not the easiest and most stable solution…</div></div></div></div></blockquote><div><br></div><div></div><div>In one project, we are using one submodule. Definitively not easy. I have no idea how submodules would work with forks and PR. Additionally, submodules do not help in making the broad changes across multiple modules. AFAIU, Git subtrees would be similar.</div><div><br></div><div>Vaclav<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><div><div><blockquote type="cite"><div>On 27 May 2019, at 08:55, Rainer M Krug <<a href="mailto:Rainer@krugs.de" target="_blank">Rainer@krugs.de</a>> wrote:</div><br class="gmail-m_-8752213531701942074Apple-interchange-newline"><div><div style="overflow-wrap: break-word;">I am no git expert, so this could be completely off. But as far as I understand it, git submodules (<a href="https://git-scm.com/book/en/v2/Git-Tools-Submodules" target="_blank">https://git-scm.com/book/en/v2/Git-Tools-Submodules</a>) are exactly for this purpose.<div><br></div><div>From their description:</div><div><br></div><blockquote style="margin:0px 0px 0px 40px;border:medium none;padding:0px"><div><div class="gmail-m_-8752213531701942074paragraph" style="box-sizing:border-box;color:rgb(78,68,60);font-family:adelle,Georgia,"Times New Roman",serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(252,252,250)"><p style="margin:0px 0px 11px;line-height:22px;box-sizing:border-box;font-family:sans-serif">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.</p></div></div><div><div class="gmail-m_-8752213531701942074paragraph" style="box-sizing:border-box;color:rgb(78,68,60);font-family:adelle,Georgia,"Times New Roman",serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(252,252,250)"><p style="margin:0px 0px 11px;line-height:22px;box-sizing:border-box;font-family:sans-serif">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.</p></div></div><div><div class="gmail-m_-8752213531701942074paragraph" style="box-sizing:border-box;color:rgb(78,68,60);font-family:adelle,Georgia,"Times New Roman",serif;font-size:14px;font-variant-ligatures:normal;background-color:rgb(252,252,250)"><p style="margin:0px 0px 11px;line-height:22px;box-sizing:border-box;font-family:sans-serif">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.</p></div></div></blockquote><div><div><br></div><div>The different add-ons could be added as submodules, so they </div><div><ul><li>would be in separate repos, </li><li>you don’t have to download all if you are only working on one, </li><li>the core team can exclude them easily if they do not work anymore from the general build process (and re-add them as easy),</li><li>Are treated, when complaint (as mentioned the windows binaries) as one single repo.</li><li>Developers of add-ons do not need write access to the core repo</li></ul><div><br></div><div>Here is another link to the GitHub blog on how they can be used: <a href="https://github.blog/2016-02-01-working-with-submodules/" target="_blank">https://github.blog/2016-02-01-working-with-submodules/</a></div><div><br></div><div>Cheers,</div><div><br></div><div>Rainer</div><div><br></div></div><div><br></div><div><br></div><div><br><blockquote type="cite"><div>On 25 May 2019, at 17:04, Markus Neteler <<a href="mailto:neteler@osgeo.org" target="_blank">neteler@osgeo.org</a>> wrote:</div><br class="gmail-m_-8752213531701942074Apple-interchange-newline"><div><div>On Fri, May 24, 2019 at 4:25 PM Stefan Blumentrath<br><<a href="mailto:Stefan.Blumentrath@nina.no" target="_blank">Stefan.Blumentrath@nina.no</a>> wrote:<br><blockquote type="cite"><br>Hi,<br><br>Collecting addons in a central repo seems very valuable to me too, for all the reasons Vacslav mentioned.<br></blockquote><br>+1<br><br><blockquote type="cite">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?<br></blockquote><br>Exactly.<br><br><blockquote type="cite">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...<br></blockquote><br>I also prefer PRs. At least the changes have a chance to be reviewed<br>and appear more traceable.<br><br><blockquote type="cite">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...<br></blockquote><br>+1^2<br><br>Cheers,<br>Markus<br>_______________________________________________<br>grass-dev mailing list<br><a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></div></div></blockquote></div><br><div>
<div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="text-align:start;text-indent:0px"><div dir="auto" style="text-align:start;text-indent:0px">--<br>Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)<br><br></div><div dir="auto" style="text-align:start;text-indent:0px">Orcid ID: 0000-0002-7490-0066</div><div dir="auto" style="text-align:start;text-indent:0px"><br></div><div dir="auto" style="text-align:start;text-indent:0px">Department of Evolutionary Biology and Environmental Studies<br>University of Zürich<br>Office Y34-J-74<br>Winterthurerstrasse 190<br>8075 Zürich<br>Switzerland<br><br>Office:<span class="gmail-m_-8752213531701942074Apple-tab-span" style="white-space:pre-wrap"> </span>+41 (0)44 635 47 64<br>Cell: <span class="gmail-m_-8752213531701942074Apple-converted-space"> </span><span class="gmail-m_-8752213531701942074Apple-tab-span" style="white-space:pre-wrap"> </span>+41 (0)78 630 66 57<br></div><div dir="auto" style="text-align:start;text-indent:0px"><a href="mailto:Rainer.Krug@uzh.ch" target="_blank">email: Rainer.Krug@uzh.ch</a></div><div dir="auto" style="text-align:start;text-indent:0px"><span class="gmail-m_-8752213531701942074Apple-tab-span" style="white-space:pre-wrap"> </span><a href="mailto:Rainer@krugs.de" target="_blank">Rainer@krugs.de</a><br>Skype: <span class="gmail-m_-8752213531701942074Apple-converted-space"> </span>RMkrug<br><br>PGP: 0x0F52F982<br><br><br></div></div></div></div>
</div>
<br></div></div>_______________________________________________<br>grass-dev mailing list<br><a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></div></blockquote></div><br><div>
<div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="text-align:start;text-indent:0px"><div dir="auto" style="text-align:start;text-indent:0px">--<br>Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)<br><br></div><div dir="auto" style="text-align:start;text-indent:0px">Orcid ID: 0000-0002-7490-0066</div><div dir="auto" style="text-align:start;text-indent:0px"><br></div><div dir="auto" style="text-align:start;text-indent:0px">Department of Evolutionary Biology and Environmental Studies<br>University of Zürich<br>Office Y34-J-74<br>Winterthurerstrasse 190<br>8075 Zürich<br>Switzerland<br><br>Office:<span class="gmail-m_-8752213531701942074Apple-tab-span" style="white-space:pre-wrap"> </span>+41 (0)44 635 47 64<br>Cell: <span class="gmail-m_-8752213531701942074Apple-converted-space"> </span><span class="gmail-m_-8752213531701942074Apple-tab-span" style="white-space:pre-wrap"> </span>+41 (0)78 630 66 57<br></div><div dir="auto" style="text-align:start;text-indent:0px"><a href="mailto:Rainer.Krug@uzh.ch" target="_blank">email: Rainer.Krug@uzh.ch</a></div><div dir="auto" style="text-align:start;text-indent:0px"><span class="gmail-m_-8752213531701942074Apple-tab-span" style="white-space:pre-wrap"> </span><a href="mailto:Rainer@krugs.de" target="_blank">Rainer@krugs.de</a><br>Skype: <span class="gmail-m_-8752213531701942074Apple-converted-space"> </span>RMkrug<br><br>PGP: 0x0F52F982<br><br><br></div></div></div></div>
</div>
<br></div></div></div>_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-dev</a></blockquote></div></div>