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
