ocr for reviewing cross-project changes

[vlotorev]

Description and benefits

Currently, the open-code-review utility performs code reviews strictly within the boundaries of a single local repository. However, in modern infrastructure and software development, projects are frequently split across multiple dependent repositories. 

I would like to request a feature to perform cross-repository code reviews. This feature will drastically improve the accuracy of code reviews for modular architectures, embedded systems, and complex DevOps/IaC setups, preventing breaking changes across repository boundaries.

Industry Examples & Precedents

• In enterprise workflows, tools like Gerrit natively support the Topic feature, which allows developers to group multiple changes across different projects/repositories. This enables code reviews and cross-project dependent merges, ensuring that a change in a library and its implementation in an application are merged atomically as a single logical unit.

Use Cases / Examples

• Ansible Infrastructure: Roles are maintained in separate repositories, while the main playbooks reside in a different repository. The utility needs to review how changes in a role affect the playbooks.
• Microservices & Shared Libraries: A Python package (or any library) is developed in one repository and consumed by applications in other repositories. A change in the library can trigger a review context in the dependent application repositories.
• Embedded Firmware: Bootloaders, kernel drivers, HALs, and user-space applications all reside in separate repositories. Changes in API signatures often require cross-project verification.

Proposed Solution / Behavior

• Allow passing multiple local git directories to the utility via configuration file.
  • Note: The utility does not need to handle Git cloning or fetching; the CI/CD pipeline will pre-clone and prepare the required repository states locally.
• Introduce a way to define relationships between these pre-cloned directories (e.g., Directory B depends on Directory A). Actually this information can be supplied via existing --background option.
• During the analysis of a change in one component, the utility should be able to pull the context (schemas, definitions, function signatures) from neighbour git directories to provide accurate feedback.

[tayfuryldz]

I'd make the unit of review a workspace manifest rather than just accepting N arbitrary repo paths. Each entry can carry repo root, base/head revision and an optional dependency name. Then the review engine can build one cross-repo context while still keeping findings anchored to a concrete repository and diff. The first version doesn't need atomic merge semantics like Gerrit topics; getting dependency-aware context and unambiguous file/revision provenance right would already solve the review problem you described.