![]() git branch -set-upstream-to origin/master master Step 9 - Push to my forkĪnd now I can push to my forked repo and create a PR. Or if it's an older repo with master instead of main as the default branch. git branch -set-upstream-to origin/main main Set the upstream of my main branch to point to my fork. Or via HTTPS: git remote add origin remote add using https Step 7 - Fetch from my new origin git fetch origin Step 8 - Set origin main (or master) Now I can just point origin at my newly forked repo via SSH: git remote add origin :adam7/winget-pkgs remote add using ssh git remote rename origin upstream Step 6 - Make my fork the origin I'm going to want my fork to be origin so I can push there so let's rename the current origin. So off to GitHub and hit the Fork button which gives me a forked repo at Step 5 - Rename my origin repo to upstream Step 3 - Realise I should have forked firstĪt this point I remember I have no permissions on this repo, and I should have started from a fork □♂️ Step 4 - Fork I updated the version of QuickLook and was ready to push and create a PR when. ![]() Most recently I thought I'd have a look at how to contribute to the new winget package manager. You can use GitHub Desktop to complete most Git commands from your desktop, such as pushing to, pulling from, and cloning remote repositories, attributing commits, and creating pull requests, with visual confirmation of changes. At that point I always wish I could remember the steps to switch to a fork, so for the benefit of my future self this time I wrote down the steps. With GitHub Desktop, you can interact with GitHub using a GUI instead of the command line or a web browser. It seems to me that there must be some setting, remote string perhaps (or setting since fork is not a git construct), that tells a repo that it is a fork of another.I often clone a repo on GitHub or GitLab make some changes to it locally and then think I'd like to contribute my changes back to the repo. If that was not the case, I have been able merge unrelated repositories before using the command line ( merge -allow-unrelated-histories) but this seems a messy way to resolve the 's issue, as it will create duplicate very similar histories. I was happy to delete the above repos and start again, since the changes I wished to make were trivial. ![]() Perhaps it was because Desktop behaviour has changes due to software updates since they were created, and these broke Desktop's and 's 'fork detection' behaviour? When comparing GitHub Desktop vs Fork, the Slant community recommends Fork for most people. I feel like the above replicated the likely processes I used to create the problem clones. It remains a mystery to me what caused the original incarnations of the above two clones not to be able to be converted to or recognised as forks. I could however go on to create a pull request via, so success in the end. On attempting to sync forks via, it recognises they are not in sync, but presumably as I don't have write privileges to upstream, there is no option for me to sync. Although Desktop did not give me the option to create a pull request, so suspicion! On pushing via Desktop I was asked if I wanted to create a fork. This time I made the changes directly in main and committed them. Just to test whether 'not creating a new branch' was the cause of my pain, I then deleted the other repo's github clone etc., and again created a new clone using GitHub Desktop. ![]() Success, I have now been able to make changes, commit locally and create a pull request with original upstream repo as the target. It recognised correctly that I didn't have access to upstream and asked to create a fork at CaverBruce. I then created a new branch and used GitHub Desktop to publish it. To fork a repo, log in to your account and then go to the repository you want to fork. ![]() However to test the Github Desktop route (to fork creation) and recover from my immediate impasse I deleted one repo's clone and removed it from Github Desktop, TortoiseGit and local drive, and started afresh creating a clone using GitHub Desktop. So I'll take on board that best practice is to fork directly using. Although I have four clone/fork pairs of repos that are working perfectly afaik for some years. What you say makes sense, however for two clone/'fork' pairs of repos I cannot replicate this behaviour. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |