Re: [boost] [git] Write permission to branch

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 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