Boost logo

Boost :

Subject: Re: [boost] [git] Write permission to branch
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2013-12-08 23:08:45

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
>>> To
>>> ! [rejected] suncc -> master (non-fast-forward)
>>> error: failed to push some refs to
>>> ''
>>> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at