Git submodules don't work well in this situation, as the will point to a particular revision of the submodule. You'd have to constantly change the super repository whenever there was a commit in a submodule.
Sling uses Android's repo for this purpose. The super repo is called sling-aggregator [0]. A related tool we are using at our company is gitslave [1], which works ok. Usually it ends being used for tools such as source code audit or locale string extraction, that should see the entire code base. But human devs usually leverage github's search features to find code in individual repos if they don't know which repo yet. [0] https://github.com/apache/sling-aggregator [1] http://gitslave.sourceforge.net Cheers, Alex > On 05.02.2018, at 18:45, Jason E Bailey <j...@apache.org> wrote: > > Has there been any consideration of using git submodules to have a single git > repository that reflects all the other repositories? It would allow for a > central view, facilitate search, and still maintain a separation of the > individual projects. > > - Jason > > On Fri, Feb 2, 2018, at 10:16 PM, Alexander Klimetschek wrote: >> On 31.01.2018, at 00:23, Robert Munteanu <romb...@apache.org> wrote: >>> Links to commits and files from the old sling repo. For example >>> >>> * https://github.com/apache/sling/commit/368f5f9c9f6d4c0e2602065687d95e >>> b173f94b85 >>> * https://github.com/apache/sling/blob/trunk/bundles/extensions/bundler >>> esource/src/main/java/org/apache/sling/bundleresource/impl/BundleResour >>> ce.java >>> >>> These would break if we add another 'sling' repo but work since we >>> renamed 'sling' to 'sling-old-svn-mirror' and Github is adding >>> redirects. >>> […] >>> Right, but it's not about conflicts, it's about breaking old links. >>> Backwards compatiblity and all that :-) >> >> Step 2 would include the old sling repo under apache/sling again, so >> that all links work (as discussed below). >> >>> Actually that's not a bad idea :-) The only downside would be that >>> cloning the repository would be really slow due to the large size. Not >>> sure if we can work around it. >> >> Then maybe it's ok to have the aggregator list in a different repo, >> prominently linked from apache/sling, and the sling one stays as just a >> landing page repo, with mostly manually curated markdown files. Where >> cloning a large repo is not such a big deal, as it would be on people's >> local computer and already cloned (unlike the aggregator which might be >> cloned a lot by CI tools and new users). >> >> Cheers, >> Alex
