On 12/09/2013 01:48 AM, Edward Diener wrote:
On 12/8/2013 6:18 PM, Mathias Gaunard wrote:
On 09/12/2013 00:00, Edward Diener wrote:
The result is:
Pushing to https://github.com/eldiener/mplsun.git To https://github.com/eldiener/mplsun.git ! [rejected] suncc -> master (non-fast-forward) error: failed to push some refs to 'https://github.com/eldiener/mplsun.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details
What does it mean that a "pushed branch tip is behind its remote" ? All I am trying to do is 'push' this repository onto an almost entirely empty remote repository. How hard can that be with git ?
You're trying to push the local "suncc" branch to the remote "master" branch. There is already some history in the remote master branch, and your local suncc branch is not a descendant of that history. To prevent history rewriting, git is therefore refusing to branch.
How was I supposed to interpret this reality from "Updates were rejected because a pushed branch tip is behind its remote" <g> ?
Well, to start there is a few things to get used to. Using two different "helpful" GUI layers, github and tortoise does maybe help in most situations, but when something go wrong it make you description harder to interpret. The last listing you put here was clear as it could be and the kind of stuff you should put up to get help. Sorry I was off-line, good thing Mathis responded. The first commit in the master branch created by GitHub when you created an "empty" git repository -- shrug -- is not very helpful. It created most, if not all, of the problems for you. Basically it caused the two repositories to have conflicting histories, with no normal commonality. This commonality is normally created by clone, rather than creating a new repository and pushing into it. The latter would have been OK I think, just unusual, had the new repository really been empty -- shrug again ---. The GitHub way of cloning is to make a Fork. The command you used to push: git push myremote suncc:master does as Mathis wrote ask git to push your local suncc branch to a master branch at the remote end. This is asking remote git at github to merge your changes from your local suncc branch onto the tip of the remote master branch. If the commit at the tip of the remote master branch in its history contain commits that are not in the history of your suncc branch, then there is no trivial and safe "fast-forward" way of performing this merge, to a total replace is only option. "Updates were rejected because a pushed branch tip is behind its remote" Git refused to change history. There is no common commit in the two branches histories either. So effectively your command was more or less to change the complete history of the remote repository. It would change the tip of the master branch from the initial github commit to a completely unrelated commit, i.e.: they have no common history. As no branch or tag would point to the old master branch (the github initial commit), it would sort of be invisible and would likely be removed at some point during garbage collection. Nothing points to it any more and it is by definition garbage. Git is very careful about making garbage without you forcing it. Some advise: The GUI trying to helpfully lead you to make selections where some sensible default could have been better. Try to understand what you select, or use defaults and hope they make sense. In a command line you would less often ask for things you do not understand, because you don't know them, so I guess in this respects GUIs are not that helpful. Always do your non trivial stuff locally. I.e.: merge between local branches, don't push and ask the remote to merge. Pull or fetch, then fix branches locally as you would like them on the remote, then make sure you have tested what you have, then push the branches you want on the remote. If you only want changes in master, you merge to master locally and push master to master. If you cloned from a place you could write to, then all defaults is set up for you. If not change, the default push remote when you have one. -- Bjørn