What we have is a jenkinsFile so that, as part of the commit , it triggers the repository that's acting as the uber repository to update it's submodules. This could even be modified slightly so that a given submodule is only updated on it's release rather then every update.
In either case, you'd end up with a central location with a snapshot of the latest code that is individually managed in it's own repo. the whole relying on github to grep multiple search result to try to determine the root repo is friction that isn't necessary. - Jason On Wed, Feb 7, 2018, at 6:10 PM, Alexander Klimetschek wrote: > 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 >
