On 12/09/2013 05:19 AM, Edward Diener wrote:
On 12/8/2013 9:28 PM, Gavin Lambert wrote:
On 9/12/2013 13:48, Quoth Edward Diener:
If you want to erase whatever is on the remote branch (which you probably do, since it only contains a dummy commit), force the push with -f.
That worked ! Thanks !
Git is still very strange to me but hopefully I will get used to its peculiarities. It does seem very flexible but very enigmatic sometimes in its so-called explanations.
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 ?
I don't think so. To create a fork they do a clone I presume. I guess you could call a repository created with git clone a clone until you make your first change to it, then the term fork fits better.
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 was conflicts as GitHub had made some history for you in the master branch.
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.
The fact that you have more than one repository add a lot of flexibility, but there is a cost of complexity. You are best off finding patterns that work well and use them.
I should have just asked for write access to the Boost MPL git repository and then I could have pretty easily created a remote branch somewhere in Boost for my own testing I think.
Then you could just have pushed right there, a lot simpler.
(Ideally your GH repo should be your main "origin" remote but it doesn't really matter as they're all just sibling names; you just need to remember which is which when pushing/pulling.)
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.
No, the remote is the repository url or shorthand reference like origin or your myremote. In addition you specify refspec which is a branch, a commit, a tag, or some other ref. refs live in each repository and all of them are simply pointers to a commit. Take a look in .git/refs to see how simple this system really is. When you see something like origin/master, that is not a reference to the master branch on the origin repository, but it is a ref to a local read/only copy of that remote branch as it was the last time you performed pull or fetch. These are the so-called remote tracking branches. -- Bjørn