On 9/12/2013 17:19, Quoth Edward Diener:
It's easier if you create your personal GH repository as a clone/fork of the boostorg one that you're intending to modify, instead of making a new empty one (as you did). (It also works better with GH's cross-repo tracking.)
I assume there must be a way to do this on GH. Also I really don't know what the difference is when one creates another repository as a fork as opposed to cloning. Does the fork contain something the clone does not ?
Clone and fork are basically the same thing. But from the sounds of your email neither is what you did -- you created a brand new empty repository, which is a completely different thing. When you're looking at any existing repository on GitHub there's a "clone URL" shown on the right hand side, which you can use if you want to make a clone on your local PC using standard Git tools. This typically is *not* what you want to do initially, though. At the top right is a "fork" button. If you're signed in to GH, clicking this will make a cloned repository within GH that's linked back to the original repository (which makes it easier to make pull requests or to push upstream, if you have permission to do so). Once you've created a fork on GH, that's when you should use the clone URL to check out a local copy on your machine that's linked to your repository. This way you can make changes on your local machine and push them up to your forked repository on GH, and from there make pull requests (or directly push/pull upstream if you can).
If your local one was also cloned from the same source you should theoretically just have to add your GH repo as a remote and everything should mesh together nicely.
This is what I tried but since my GH repo had history git didn't like that. How odd ! Why can't it just update the history when one does a 'push' ? Why does it matter if their is previous history ? As long as their are no conflicts should not a git 'push' just work ? There is much in git that says things should be simple and just work but actually it seems it has much more checks/balances than svn had.
It's a bit different than what you tried. And Bjørn has already explained why what you tried didn't work. You would have had the same problem in SVN. The approximate SVN equivalent action would have been to check out from one repository and then try to commit to a freshly-created blank repository elsewhere. SVN won't let you do that, because the repository ids don't match. Git *will* let you do that (because it has to work with multiple repositories, and they're all equal in its eyes), but it correctly warns you that it's a dangerous thing to do. It is a fairly common difference between Git and SVN though. SVN will typically flat-out refuse to do things it thinks are potentially dangerous. Git will initially refuse to do things too but usually provides an option to do them anyway and assume you know what you're asking for and what the consequences will be.
I assume a 'remote' name is a combination of a URL and a branch and the name does not matter as long as it is unique for a given local repository.
Yes.