freemint / tos.hyp

The tos.hyp tries to document all functions from TOS. It also has information about MagiC, N.AES, MyAES, Geneva, XaAES, oAESis and some emulators.
https://freemint.github.io/tos.hyp
GNU General Public License v2.0
13 stars 10 forks source link

Correct wrong parameter name in Pgetpriority and Psetpriority system calls #87

Closed DavidGZ closed 6 years ago

DavidGZ commented 6 years ago

Sorry, commits which are from the sync of my fork with the main branch slipped into the pull request. I'm going to close it and try again.

mikrosk commented 6 years ago

@DavidGZ btw you don't need to close/open PR again -- just force push correct content to the same branch and voila.

th-otto commented 6 years ago

The problem with this approach is to get the "correct" content on the branch, once you've messed it up ;)

Somehow this sounds familiar to me ;)

DavidGZ commented 6 years ago

The problem with this approach is to get the "correct" content on the branch, once you've messed it up ;) Somehow this sounds familiar to me ;)

:-).....But is it even possible to achieve it? I was tempted to remove the fork and create it again to avoid all this headache.

I've earned some skills with git working with a cloned repository but when it's forked I still feel hopeless ;-).

To learn from my mistakes I need some help because I'm not able to find an answer elsewhere.

I followed these instructions to sync my forked repository before I added my changes to do a pull request : https://help.github.com/articles/syncing-a-fork/

Then I had a new commit that is a "merge" in my log, I don't like those commits in the history so to remove it I did "git rebase" (I think here is when I messed up things), the merge commit was gone but I think the commits that were synced got new commits IDs, so github sees them as new commits.

What should I have done to have a clean copy of the "origin" repository history?

mikrosk commented 6 years ago

@DavidGZ I'm using much simpler and rather brutal approach - if I mess something up in a branch (doesn't have to be a PR but in this case it's essential), I create another branch at master's tip, cherry pick the commit(s) I want to preserve, checkout to my messed up branch and reset to the newly created one. Then delete the newly created one (as it's no longer needed) and force push the now-ok branch back to the origin.

In essence something like this (being in the messed up branch = my_pr_branch):

git checkout master (optionally git pull) git checkout -b temp git cherry-pick <commit(s) I want to preserve> git checkout my_pr_branch git reset --hard temp git push --force

I'm writing this from top of my head but you see the idea -- no rebase, no merges, just starting from scratch.

DavidGZ commented 6 years ago

@mikrosk I followed your instructions before you edited the post, I was not able to fix the branch, later I got it fixed using rebase. But I still had the same problem when I synced the forked repository from the remote one, I get a "merge" commit that slips into the pull-request.

At the end I removed the forked repo and created it again, I've done a new pull-request.

In any case I'd like to know how I should have done it without deleting the forked repo.