3 ms·

There’s nothing preventing you from having a single pull request in for merging branches over multiple repos. There’s nothing preventing you from having a paren

by audunw 2y ago

There’s nothing preventing you from having a single pull request in for merging branches over multiple repos. There’s nothing preventing you from having a parent repo with a lock file that gives you a single linear set of commits tracking the state of multiple repos. That is, if you’re not tied to using just Github of course. Big monorepos and multiple repo solutions require some tooling to deal with scaling issues. What surprises me is the attitude that monorepos are the right solution to these challenges. For some projects it makes sense yes, but it’s clear to me that we should have a solution that allows repositories to be composed/combined in elegant ways. Multi-repository pull requests should be a first class feature of any serious source code management system. If you start two projects separately and then later find out you need to combine their history and work with them as if they were one repository, you shouldn’t be forced to restructure the repositories.

pelletier 2y ago
> Multi-repository pull requests should be a first class feature of any serious source code management system. Do you have examples of source code management systems that provide this feature and do you have experience with them? repo-centric approach of GitHub often feels limiting.
- jvolkman 2y ago
  Apparently Gerrit supports this with topics: https://gerrit-review.googlesource.com/Documentation/cross-repository-changes.html https://gerrit-review.googlesource.com/Documentation/cross-r...
- jamesfinlayson 2y ago
  At a company I used to be at they used GitHub Enterprise and some repos definitely seemed to have linked repos or linked commits (I don't remember exactly but there was some way of linking for repos that depended on each other).
- zelphirkalt 2y ago
  It is very easy to build this yourself. Just use your dependency manager of choice that has git support and create a config of versions of the repos and lock file that. Whenever you have a change across multiple services, simply change that config in one go, so that every commit of that config describes a deployable state of the whole project.
  - williamdclt 2y ago
    I might be misunderstanding but that seems off-topic, not related to the idea of "multi-repository pull requests"
CharlieDigital 2y ago
> Multi-repository pull requests should be a first class feature of any serious source code management system. But it's currently not? > If you start two projects separately and then later find out you need to combine their history and work with them as if they were one repository, you shouldn’t be forced to restructure the repositories. It's called a directory copy. Cut + paste. I'd add a tag with a comment pointing to the old repo (if needed). But probably after a few weeks, no one is going to look at the old repo.
- dmazzoni 2y ago
  > It's called a directory copy. Cut + paste. I'd add a tag with a comment pointing to the old repo (if needed). But probably after a few weeks, no one is going to look at the old repo. Not in my experience. I use "git blame" all the time, and routinely read through commits from many years ago in order to understand why a particular method works the way it does. Luckily, there are many tools for merging git repos into each other while preserving history. It's not as simple as copy and paste, but it's worth the extra efford.
  - deleted 2y ago
    [deleted]
  - CRConrad 2y ago
    Any tips on where to find these tools, or just generally find out how that works?
    - oftenwrong 2y ago
      An approach I've used is to use https://github.com/newren/git-filter-repo https://github.com/newren/git-filter-repo (amazing, versatile tool) to put the tree into a subdirectory, and namespace its tags, and then merge that into another tree with --allow-unrelated-histories. I built a tool for an employer that automated this process for the purpose of consolidating an excessive number of repositories.

by audunw 2y ago

pelletier 2y ago

> Multi-repository pull requests should be a first class feature of any serious source code management system. Do you have examples of source code management systems that provide this feature and do you have experience with them? repo-centric approach of GitHub often feels limiting.

jvolkman 2y ago
Apparently Gerrit supports this with topics: https://gerrit-review.googlesource.com/Documentation/cross-repository-changes.html https://gerrit-review.googlesource.com/Documentation/cross-r...
jamesfinlayson 2y ago
At a company I used to be at they used GitHub Enterprise and some repos definitely seemed to have linked repos or linked commits (I don't remember exactly but there was some way of linking for repos that depended on each other).
zelphirkalt 2y ago
It is very easy to build this yourself. Just use your dependency manager of choice that has git support and create a config of versions of the repos and lock file that. Whenever you have a change across multiple services, simply change that config in one go, so that every commit of that config describes a deployable state of the whole project.
- williamdclt 2y ago
  I might be misunderstanding but that seems off-topic, not related to the idea of "multi-repository pull requests"

CharlieDigital 2y ago

> Multi-repository pull requests should be a first class feature of any serious source code management system. But it's currently not? > If you start two projects separately and then later find out you need to combine their history and work with them as if they were one repository, you shouldn’t be forced to restructure the repositories. It's called a directory copy. Cut + paste. I'd add a tag with a comment pointing to the old repo (if needed). But probably after a few weeks, no one is going to look at the old repo.

dmazzoni 2y ago
> It's called a directory copy. Cut + paste. I'd add a tag with a comment pointing to the old repo (if needed). But probably after a few weeks, no one is going to look at the old repo. Not in my experience. I use "git blame" all the time, and routinely read through commits from many years ago in order to understand why a particular method works the way it does. Luckily, there are many tools for merging git repos into each other while preserving history. It's not as simple as copy and paste, but it's worth the extra efford.
- deleted 2y ago
  [deleted]
- CRConrad 2y ago
  Any tips on where to find these tools, or just generally find out how that works?
  - oftenwrong 2y ago
    An approach I've used is to use https://github.com/newren/git-filter-repo https://github.com/newren/git-filter-repo (amazing, versatile tool) to put the tree into a subdirectory, and namespace its tags, and then merge that into another tree with --allow-unrelated-histories. I built a tool for an employer that automated this process for the purpose of consolidating an excessive number of repositories.