overengineeringstudio / overengineeringstudio/effect-utils

Megarepo: nested pin propagation for cross-repo PR stacks

Open
#395 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

origin:agent type:agent-tooling
Dominant language
TypeScript
Stars
82
Forks
2
Avg merge
1d 8h
Merged PRs (30d)
121

Description

Problem

When validating a cross-repo PR stack before merging upstream, downstream repos pin the upstream member (e.g., effect-utils) to a PR branch via mr config pin. However, repos with nested megarepos (e.g., dotfiles contains repos/private-shared and repos/livestore) fail in CI because:

  1. The parent pins effect-utils to the PR branch ✓
  2. CI runs mr apply --all which clones nested members (private-shared, livestore)
  3. Nested members are cloned at their default branch (from the parent's lock)
  4. Nested members' own megarepo.json still references effect-utils at main
  5. Nested sync tries to clone effect-utils at mainstore conflict with the parent's PR branch clone

Current tools

  • mr config push-refs --all propagates refs from parent megarepo.json to nested members' megarepo.json through symlinks
  • But local symlinks point to default branch worktrees, not PR branch worktrees
  • So push-refs modifications go to the wrong branch

Desired behavior

When a parent megarepo pins a member to a non-default ref, mr apply --all should ensure nested members can resolve that member consistently. Options:

  1. Ref propagation in apply: when cloning nested members, inject the parent's pinned ref into the nested member's config before nested sync runs
  2. Store-level dedup: if effect-utils is already in the store at a non-default ref, allow nested sync to reuse it instead of requiring an exact ref match
  3. Cascade pin workflow: mr config push-refs should be able to target PR branch worktrees (not just default branch symlinks)

Workaround

Merge upstream first (topological order), then downstream PRs validate against merged main.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing mr apply --all and mr config push-refs --all, then inspect how nested megarepo.json files and store refs are resolved. Compare the three proposed approaches and determine which behavior lets nested members reuse the parent's pinned ref without a store conflict; done means cross-repo PR stacks validate in CI without the described workaround.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
cli, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.