2w ago

How the GitHub CLI can now enable triangular workflows

For those familiar with Git terminology:

The simplest way to assemble a triangular workflow is to set the branch’s merge key to a different branch name, like so:
 
    
[branch “branch”]
   remote = origin
   merge = refs/heads/default


  
This will result in the branch pullRef as origin/default, but pushRef as origin/branch, as shown in Figure 9.

Working with triangular forks requires a bit more customization than triangular branches because we are dealing with multiple remotes. […]

GitHub @programming.dev

Nemeski @lemm.ee

2w ago

How the GitHub CLI can now enable triangular workflows

github.blog /open-source/git/how-the-github-cli-can-now-enable-triangular-workflows/

5 comments

Sorry, I'm a square.
- No, you're the letter j
  Anyways, I'm assuming you don't understand what the triangular workflow is (if i assumed wrong, ignore this)? Imagine you want to make an improvement to Lemmy. You got to github.com/lemmynet/lemmy, you fork that repository and you add your improvement. Now you can't just push you improvement back to that repository, because you don't have the rights to push to that repository. So you have to make your own repository at github.com/theletterj/lemmy and make a nerge request to github.com/lemmynet/lemmy to merge your improvement.
  That is the triangle. You have to pull from github/lemmynet, but push to guthub/theletterj and send a merge request back to github/lemmynet
  
  How is that different from sending a PR?