I don't know GitHub's buttonology for this, but what you showed in green would be a rebate then merge, so that does seem likely.
-- Ian From my Fairphone FP3
On Thu, 22 Oct 2020, 05:33 Greg Ercolano, wrote:
On 2020-10-21 20:59, Greg Ercolano
wrote:
So I have a question about how to handle PRs. I keep running into this and I just don't get it:
Someone makes an issue
You create a branch on your fork to solve
You create a PR
Some more work is done during the PR to further craft the solution
Solution is reached, but everyone's tired -- will do the merge later
Weeks, maybe months pass because of.. whatever
So now FLTK's master has had dozens of commits, and your branch is based on some
now far away commit, and you remember you never merged your work.
Simply, what steps do you do at this point to complete the merge of the pull request?
Just to be clear what I'm looking for, here's the 'before' in
my local fork:
O most recent commit (origin/master)
O new-commit
O new-commit
O new-commit
O new-commit
O new-commit
O new-commit
O new-commit
| O my branch commit 2
| O my branch commit 1
| O my branch
O new-commit /
O new-commit-my-branch-was-based on
O old-commit
O old-commit
..
..and here's where I think I want to be after resolving the PR
in the upstream master fltk:
O my merge commit (origin/master)
| \
| O my branch commit 2
| O my branch commit 1
| O my branch
| /
O most recent commit
O new-commit
O new-commit
O new-commit
O new-commit
O new-commit
O new-commit
O new-commit
O commit-my-branch-was-based on
O old-commit
O old-commit
..
Is this perhaps a one button thing in github using "Rebase
and merge"? i.e.
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.