![]() ![]() 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. 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? 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. 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. If youre using Github, the easiest method to fork a repository is to click the 'Fork' button, which will automatically make a new repository in your account and set up the remotes when you clone it. 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 |