undefined | Better HN

0 pointsJoshTriplett7mo ago0 comments

That doesn't help if you actually need those repositories to exist separately.

For instance, consider the problem of having an external Open Source project your company maintains or heavily contributes to, and which also has common libraries shared with internal non-public work. Or, the same problem applies if you have a downstream Open Source project that needs to incorporate and vendor an upstream one but easily contribute changes upstream.

Some folks do this by generating the external repo as a filtered version of an internal monorepo, but that's awful in so many ways, and breaks the ability to properly treat the external repo as a first-class thing that can merge PRs normally. It leads to workflows where people submitting PRs feel like their work gets absorbed internally and maybe eventually spit back out the other end, rather than just being merged.

0 comments

gpm7mo ago

Is the pain with publishing a subsetted version of the internal monorepo anything but a tooling limitation where things like pushing into that that subsetted version, and merging changes made on the subsetted version, aren't automatic because our tools don't natively understand subsets?

It would require forge integration, but I'd like a world where I could make a PR to `company/open-source-subdir` and the company could merge that PR and that was that without any extra steps because open-source-subdir is just a publicly published subset of the `company` repo.

JoshTriplettOP7mo ago

No, it's not just a tooling limitation. Or, at least, not one solvable just by having forges expose public subsets of private repos. That might partially solve the simplest case of `company/open-source-subdir`, if the company trusts the forge tooling to handle subsetting and to not expose more than they want, but it doesn't solve the more general problem.

Consider the case where the repositories are owned by different entities, for instance, or have different governance. For instance, Project X needs to vendor Project Y, and have a few downstream patches that they're working on upstreaming.

Right now, the two major options include:

- Use a submodule. Experience all the pain of submodules.

- Use some tooling to fold the repo into your own repo. Extract commits from it when you want to upstream. Experience all the pain of not having the original commits and the ability to easily pull/merge/cherry-pick/rebase, plus pain when you make changes across that repo and other code.

j / k navigate · click thread line to collapse