for #14186 i had to rebase my fork and development branch to the latest version of openhab-addons to get rid of some build errors.
From what i can remember, I did this by:
git checkout main (go to the main of my fork)
git rebase origin/main
git checkout hapero (my branch)
git rebase main
that all went ok.
When i pushed to my branch, i have now hundreds of commits showing as mine (seemingly all commits since i last rebased) and also hundreds of review requests on my PR.
I had this problem once earlier when is tried to update my branch via the github gui, which as i learned does a merge instead of a rebase. But with a rebase, from what i know about git, this should not have happened. I think i really need help from here
I would really appreciate if someone could help me out with:
Removing all those review requests to not annoy about everyone who ever committed to the project, it seems i cant do that myself
Showing me how to fix my branch so it only shows my commits, not everybody elses
Last but not least, explain me what is the correct way to rebase to avoid this in the future ?
And, yes of course i tried googling it but i came up with 5 or 6 possible solutions and i do not want to try them all out because that for sure is going to make it worse.
As a relative Noob, github has kindly provided endless hours of frustration. I have had your problem and many others (particularly that in the signoff the email address needs to be in ā<>ā -if it is shown as a link it will not work). There may be smarter ways, but my current strategy if I screw-up is to delete my fork and start over. To avoid a lot of rework, I save the file(s) I modified somewhere else, delete the fork (which is also hard to find how). This will close the PR (if there is a lot of conversation you could link of copy to your new one). Then I refork the repository and edit the files and resubmit the PR. Total brute force.
The first steps are wrong cause if you do git rebase main while being on local main branch you risk rewritting a whole bunch of commits made by others.
The purpose of rebase is to be executed with small amount of commits, primarily on local branches before merging them into main.
If you have situation where you have rewritten others commits best way is to start new branch from main and git cherry-pick your commits one by one in new branch. Next time when you want to rebase you can do git pull ārebase.
Should I make more detailed instruction to fix your branch?
No, āgit logā shows the original authors, its only the pull request. Or actually, DCO is complainig about 140 incorrectly signed commits, which makes me believe it is seeing those as mine and complains about the wrong author.
If it is not too much hassle for you, i would appreciate that!
Otherwise, i guess I go with @apella12 's solution, backup my work, delete the branch to close the PR and start with a new branch.
First of all, you can rebase against a remote branch directly.
git fetch --all
git checkout my_local_branch
git rebase upstream/main
But if you do end up in a situation where the rebase cannot be saved, you can always do git show a_particular_commit > /tmp/foo.patch if you only have a single commit or git diff origin/main > /tmp/foo.patch followed by creating a new clean branch and then patch -p1 < /tmp/foo.patch
I think i basically followed the shorthand way posted by @splatch in that post, i only did a āgit rebaseā instead of a āgit pull --rebaseā. (I thought āgit rebaseā is does the same) This has also already worked once for me in the past but this time it went completely sideways.
Edit: As i type it dawned on me what the difference is. pull --rebase obviously makes a pull first, then a rebase.
You could also use the same branch name when starting from scratch, and then force push that and reopen the pull request. Then history and comments would be preserved, which would save time for existing reviewers.
