What problem are you trying to solve?
We want to use OpenKnowledge as a centralized knowledge base for our organization, but documentation are distributed across a large number of Git repositories (around 10 repositories).
Currently, it seems that an OpenKnowledge project is designed around a single Git repository. This makes it difficult to use OpenKnowledge as an organization-wide knowledge layer when working with a microservice architecture where each service has its own repository.
Our goal is to have one knowledge base that can contain and search knowledge from many independent repositories while keeping the source repository information.
For example:
service-a repo ─┐
service-b repo ─┤
service-c repo ─┤
infrastructure ─┤
terraform repo ─┘
↓
OpenKnowledge
↓
Unified Knowledge
↓
Single MCP
This would allow developers and AI agents to query organizational knowledge without needing to know which repository contains the relevant information.
Proposed solution
Allow a single OpenKnowledge project/workspace to connect to and synchronize multiple Git repositories.
One possible implementation could be to use Git submodules, allowing each repository to remain independent while being referenced from a central OpenKnowledge repository. Synchronization could then use recursive Git operations such as git pull --recurse-submodules or git submodule update --init --recursive.
Each repository could be treated as an independent source within the same knowledge base.
Ideally:
Repositories can be added or removed independently.
Each repository can be synchronized independently.
Documents retain metadata about their source repository.
Search and MCP queries work across all repositories.
Repositories can optionally be grouped or namespaced.
Private repositories are supported.
Git providers such as GitHub, GitLab, and Bitbucket are supported.
For example:
OpenKnowledge Workspace
├── services/
│ ├── service-a → Git submodule
│ ├── service-b → Git submodule
│ └── service-c → Git submodule
├── infrastructure → Git submodule
└── terraform-modules → Git submodule
The parent repository could maintain references to the individual repositories, while OpenKnowledge indexes their content as part of the same workspace.
All of these sources would then be searchable through the same OpenKnowledge interface and exposed through a single MCP endpoint.
Git submodules are only one possible implementation approach; the main requirement is native support for aggregating and synchronizing multiple independent Git repositories within a single OpenKnowledge knowledge base.
Area
GitHub sync
Alternatives considered
No response
What problem are you trying to solve?
We want to use OpenKnowledge as a centralized knowledge base for our organization, but documentation are distributed across a large number of Git repositories (around 10 repositories).
Currently, it seems that an OpenKnowledge project is designed around a single Git repository. This makes it difficult to use OpenKnowledge as an organization-wide knowledge layer when working with a microservice architecture where each service has its own repository.
Our goal is to have one knowledge base that can contain and search knowledge from many independent repositories while keeping the source repository information.
For example:
service-a repo ─┐
service-b repo ─┤
service-c repo ─┤
infrastructure ─┤
terraform repo ─┘
↓
OpenKnowledge
↓
Unified Knowledge
↓
Single MCP
This would allow developers and AI agents to query organizational knowledge without needing to know which repository contains the relevant information.
Proposed solution
Allow a single OpenKnowledge project/workspace to connect to and synchronize multiple Git repositories.
One possible implementation could be to use Git submodules, allowing each repository to remain independent while being referenced from a central OpenKnowledge repository. Synchronization could then use recursive Git operations such as git pull --recurse-submodules or git submodule update --init --recursive.
Each repository could be treated as an independent source within the same knowledge base.
Ideally:
Repositories can be added or removed independently.
Each repository can be synchronized independently.
Documents retain metadata about their source repository.
Search and MCP queries work across all repositories.
Repositories can optionally be grouped or namespaced.
Private repositories are supported.
Git providers such as GitHub, GitLab, and Bitbucket are supported.
For example:
OpenKnowledge Workspace
├── services/
│ ├── service-a → Git submodule
│ ├── service-b → Git submodule
│ └── service-c → Git submodule
├── infrastructure → Git submodule
└── terraform-modules → Git submodule
The parent repository could maintain references to the individual repositories, while OpenKnowledge indexes their content as part of the same workspace.
All of these sources would then be searchable through the same OpenKnowledge interface and exposed through a single MCP endpoint.
Git submodules are only one possible implementation approach; the main requirement is native support for aggregating and synchronizing multiple independent Git repositories within a single OpenKnowledge knowledge base.
Area
GitHub sync
Alternatives considered
No response