5 ms·

It would also be nice to have a way to link multiple PRs together so they can be merged simultaneously. A ton of people are working across multiple repos which

It would also be nice to have a way to link multiple PRs together so they can be merged simultaneously. A ton of people are working across multiple repos which makes reviewing and coordinating changes really annoying.

morley 8y ago
Why not have everyone create their PRs against a feature branch instead of master, and merge the feature branch into master when the project is done?
- rhinoceraptor 8y ago
  I don't mean multiple PRs for the same repo, I mean multiple PRs across multiple repos.
- no_wizard 8y ago
  Well, if you practice trunk based development, (which at most, is short lived branches that aren't really suppose to last beyond 72 hours for development purposes), its not always best practice: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ The heart of this being this point: sometimes the workflow of the team demands different ways of thinking about it, and its nice to have that flexibility. Edit: worth noting also, this does something for those of us using this methodology (I am a big promoter of trunk based development with ruthless purging of short lived feature branches) Opening WIP PR allows everyone to see several things: 1. what issue is being worked on 2. that it is claimed by someone 3. When that issue was started to being worked on 4. The intentions in solving the issue (if done right) Those are real wins. I wonder if the hub client will get a open draft PR option soon.
jiveturkey 8y ago
Do you mean link multiple PRs across multiple repos? You can already merge multiple commits together in the same PR, in a single repo, of course. via branches. If so, this can't be done within git, since the overall container is a single repo.[1] There is no atomicity or even coordination between repos. You can get loose coordination though via integration with an issue tracker like jira. The tracker links multiple PRs across multiple repos into a single meta-merge. But you aren't going to get "simultaneous merge" in the sense of a single atomic cross-PR and cross-repo commit. [1] One of the things that is awful with github [not git itself], is that all your controls such as commit rules, privileges, visibility, have the granularity of the entire repo. Even though awful, this is the right approach considering that many git restrictions are per-repo, eg branches. vs perforce, eg
- rhinoceraptor 8y ago
  Yes, I'm talking about coordinating PRs against multiple repos. Obviously, this isn't a git feature, this is something that Github would need to do, just like issues/webhooks/comments are not git features. This is one of the reasons cited for monorepos, you can make a single atomic commit/PR that changes some API, and the consumers of that API. As it is now, you end up writing a warning comment to merge some other PR at the same time and hoping your reviewers read it.
  - jiveturkey 8y ago
    or use a capable issue tracker. honestly, any project where you need to do such coordination needs such an issue tracker anyway.
sjjshvuiajhz 8y ago
I think the way git supports this workflow currently is to have a super-repo containing all the other repos as submodules. You can bundle all those changes together as updates to the submodule references in a single PR.
- jacques_chester 8y ago
  In my experience, this is like waltzing barefoot with Satan.
  - sjjshvuiajhz 8y ago
    I don’t love submodules, but I think the difficultly comes because they require experience to use properly and you have to learn the gotchas, like everything else in git. IMO a workflow that requires synchronized versioning across repos is inherently complicated, and that complexity is hard to hide. Submodules are probably better than manually keeping everything in sync with tribal knowledge, which you are probably doing if your PR includes instructions to merge at the same time as another PR.
DogLover_ 8y ago
One of the benefits of mono-repos
- pageandrew 8y ago
  we have ~10 actively developed independent repositories, and this is one of the primary reasons I wish we had a mono-repo
mariojv 8y ago
Gerrit supports this feature. You just add "Depends-On: changeID" in your commit message.
ognarb 8y ago
Phabricator can do it, you can add child revisions to any differential. It's quite nice.

morley 8y ago

Why not have everyone create their PRs against a feature branch instead of master, and merge the feature branch into master when the project is done?

rhinoceraptor 8y ago
I don't mean multiple PRs for the same repo, I mean multiple PRs across multiple repos.
no_wizard 8y ago
Well, if you practice trunk based development, (which at most, is short lived branches that aren't really suppose to last beyond 72 hours for development purposes), its not always best practice: https://trunkbaseddevelopment.com/ https://trunkbaseddevelopment.com/ The heart of this being this point: sometimes the workflow of the team demands different ways of thinking about it, and its nice to have that flexibility. Edit: worth noting also, this does something for those of us using this methodology (I am a big promoter of trunk based development with ruthless purging of short lived feature branches) Opening WIP PR allows everyone to see several things: 1. what issue is being worked on 2. that it is claimed by someone 3. When that issue was started to being worked on 4. The intentions in solving the issue (if done right) Those are real wins. I wonder if the hub client will get a open draft PR option soon.

jiveturkey 8y ago

Do you mean link multiple PRs across multiple repos? You can already merge multiple commits together in the same PR, in a single repo, of course. via branches. If so, this can't be done within git, since the overall container is a single repo.[1] There is no atomicity or even coordination between repos. You can get loose coordination though via integration with an issue tracker like jira. The tracker links multiple PRs across multiple repos into a single meta-merge. But you aren't going to get "simultaneous merge" in the sense of a single atomic cross-PR and cross-repo commit. [1] One of the things that is awful with github [not git itself], is that all your controls such as commit rules, privileges, visibility, have the granularity of the entire repo. Even though awful, this is the right approach considering that many git restrictions are per-repo, eg branches. vs perforce, eg

rhinoceraptor 8y ago
Yes, I'm talking about coordinating PRs against multiple repos. Obviously, this isn't a git feature, this is something that Github would need to do, just like issues/webhooks/comments are not git features. This is one of the reasons cited for monorepos, you can make a single atomic commit/PR that changes some API, and the consumers of that API. As it is now, you end up writing a warning comment to merge some other PR at the same time and hoping your reviewers read it.
- jiveturkey 8y ago
  or use a capable issue tracker. honestly, any project where you need to do such coordination needs such an issue tracker anyway.

sjjshvuiajhz 8y ago

I think the way git supports this workflow currently is to have a super-repo containing all the other repos as submodules. You can bundle all those changes together as updates to the submodule references in a single PR.

jacques_chester 8y ago
In my experience, this is like waltzing barefoot with Satan.
- sjjshvuiajhz 8y ago
  I don’t love submodules, but I think the difficultly comes because they require experience to use properly and you have to learn the gotchas, like everything else in git. IMO a workflow that requires synchronized versioning across repos is inherently complicated, and that complexity is hard to hide. Submodules are probably better than manually keeping everything in sync with tribal knowledge, which you are probably doing if your PR includes instructions to merge at the same time as another PR.

DogLover_ 8y ago

One of the benefits of mono-repos

pageandrew 8y ago
we have ~10 actively developed independent repositories, and this is one of the primary reasons I wish we had a mono-repo

mariojv 8y ago

Gerrit supports this feature. You just add "Depends-On: changeID" in your commit message.

ognarb 8y ago

Phabricator can do it, you can add child revisions to any differential. It's quite nice.