4 ms·

You know what would be cool? If I could create a fork off the project i was using. Then I write a feature I need in that project. it becomes a PR, but then the

You know what would be cool? If I could create a fork off the project i was using. Then I write a feature I need in that project. it becomes a PR, but then the fork is also automatically (if possible) updated whenever the main branch is updated. If it can't be updated automatically you are notified to update your fork against the upstream changes. This would have many benefits, including easy testing of PRs, forks that don't stale, and overall helping closing the loop on open PRs.

mikepurvis 10y ago
I don't know about "automatically", since all the hashes would change, but I definitely do wish that Github had better tools for managing long term forks, especially web workflows for: - rebase this branch on upstream - resolve merge/rebase conflicts - make my master be upstream's master with PRs X, Y, and Z applied to it in that order. I find the last one in particular to be awful, where I'm iterating on multiple PRs with an upstream, and keeping them separate for the sake of review, but wanting to test as a group to validate the end-to-end functionality. It can be a huge hassle cherry picking and rebasing commits between branches.
- daurnimator 10y ago
  > resolve merge/rebase conflicts This was added to github rather recently
- akkartik 10y ago
  Have you considered just constantly rebasing as you pull? This works well for private forks, but it may also be doable for public forks if you explain what's going on in the Readme. Just an idea. I know it goes against everything we learn about Git, but perhaps it's not so bad in this particular situation.
  - mikepurvis 10y ago
    Yeah, I mean that's basically what you do, but it becomes a huge pain if you're making more than one contribution upstream. You feature-branch-1, feature-branch-2, and then the upstream master with those two branches merged into it. When you update either one of the two PRs, you need to rewind the upstream master and reapply the two merges onto it. Maybe that doesn't sound so bad, but it feels super awkward to me.
    - akkartik 10y ago
      Ah, I see. Makes more sense when I reread it now. I'm just not juggling multiple patches at a time like this, but it's a valid workflow.

mikepurvis 10y ago

I don't know about "automatically", since all the hashes would change, but I definitely do wish that Github had better tools for managing long term forks, especially web workflows for: - rebase this branch on upstream - resolve merge/rebase conflicts - make my master be upstream's master with PRs X, Y, and Z applied to it in that order. I find the last one in particular to be awful, where I'm iterating on multiple PRs with an upstream, and keeping them separate for the sake of review, but wanting to test as a group to validate the end-to-end functionality. It can be a huge hassle cherry picking and rebasing commits between branches.

daurnimator 10y ago
> resolve merge/rebase conflicts This was added to github rather recently
akkartik 10y ago
Have you considered just constantly rebasing as you pull? This works well for private forks, but it may also be doable for public forks if you explain what's going on in the Readme. Just an idea. I know it goes against everything we learn about Git, but perhaps it's not so bad in this particular situation.
- mikepurvis 10y ago
  Yeah, I mean that's basically what you do, but it becomes a huge pain if you're making more than one contribution upstream. You feature-branch-1, feature-branch-2, and then the upstream master with those two branches merged into it. When you update either one of the two PRs, you need to rewind the upstream master and reapply the two merges onto it. Maybe that doesn't sound so bad, but it feels super awkward to me.
  - akkartik 10y ago
    Ah, I see. Makes more sense when I reread it now. I'm just not juggling multiple patches at a time like this, but it's a valid workflow.