Open Stack

Andreas Jaeger <aj at suse.com> wrote:
>On 2017-03-06 07:10,  Bernd Bausch   wrote:
>> Rather than cloning the entire OpenStack docs repo again, I thought I would
>> follow the instructions[1], went to the local copy I cloned a few weeks ago
>> and issued the commands below - which ultimately failed:
>>
>> [bbausch at ceres openstack-manuals]$ git remote update
>> Fetching origin
>> remote: Counting objects: 4911, done.
>> remote: Compressing objects: 100% (1577/1577), done.
>> remote: Total 3727 (delta 2581), reused 2715 (delta 1648)
>> Receiving objects: 100% (3727/3727), 5.16 MiB | 625.00 KiB/s, done.
>> Resolving deltas: 100% (2581/2581), completed with 351 local objects.
>> From https://git.openstack.org/openstack/openstack-manuals
>>    c251097..e6f7e32  master     -> origin/master
>>    a7ac312..b5ba71b  stable/mitaka -> origin/stable/mitaka
>>    306f430..0940625  stable/newton -> origin/stable/newton
>> Fetching gerrit
>> From ssh://review.openstack.org:29418/openstack/openstack-manuals
>>    c251097..e6f7e32  master     -> gerrit/master
>>    a7ac312..b5ba71b  stable/mitaka -> gerrit/stable/mitaka
>>    306f430..0940625  stable/newton -> gerrit/stable/newton
>>
>> This looks good!
>>
>> [bbausch at ceres openstack-manuals]$ git checkout master
>> Already on 'master'
>> Your branch and 'origin/master' have diverged,
>> and have 1 and 434 different commits each, respectively.
>>   (use "git pull" to merge the remote branch into yours)
>>
>> Yes, the instructions do talk about doing a pull.
>>
>> [bbausch at ceres openstack-manuals]$ git pull --ff-only origin master
>> remote: Counting objects: 24, done.
>> remote: Compressing objects: 100% (11/11), done.
>> remote: Total 13 (delta 11), reused 3 (delta 2)
>> Unpacking objects: 100% (13/13), done.
>> From https://git.openstack.org/openstack/openstack-manuals
>>  * branch            master     -> FETCH_HEAD
>>    e6f7e32..d7ad707  master     -> origin/master
>> fatal: Not possible to fast-forward, aborting.
>>
>> That's an error, right? Unfortunately, it doesn't tell me what's wrong.
>>
>> Admittedly, to me Git continues to be black magic. All I can do is
>> copy-paste magical incantations. Without access to a fellow shaman, I am
>> stuck if they don't work.

Well, the internet is full of fantastic documentation, tutorials,
videos etc. on git, so there is a way to address this ;-)  I can
highly recommend everything linked from here:

    https://git-scm.com/doc

>> Apart from just cloning the whole 700MB or so of openstack-docs, are there
>> any suggestions how to tackle this error?
>>
>> This is not a showstopper, but would be nice to know.
>
>Run "git reset --hard origin/master" to get your tree in sync with the
>remote one. That's a last resort one ;)

Right - but be aware that this could lose some of your local-only
changes.  To avoid that you could first save the commit which master
is pointing to as a new branch head:

    git branch mytopic master

This is effectively taking a copy of the state of the master branch
into a new branch called "mytopic" so that you are then free to safely
reset master to origin/master which is the latest upstream.

>"git status" afterwards should be fine.
>
>In general: If you send patches, it's best to do them on a separate
>branch for the gerrit workflow. Then you should never run into these
>problems.
>
>So:
>git checkout master
>git pull
>git checkout -b new-branch
>... and now your edits
>git review
>
>And continue on another branch for the next change

Andreas is 100% right, but it's probably worth also being explicit
about the cause of the error, not just how to avoid it: your local
master branch contains commits which are not in the upstream
origin/master branch.  This is not best practice in this context (nor
in many others).  As a result your local master branch cannot be
"fast-forwarded" in a purely linear fashion to catch up with
origin/master, and since you specified --ff-only, git will refuse to
catch up master with origin/master by doing a merge of the two.  So
this shows that using --ff-only was a good idea, because it acted as a
safety mechanism which prevented this unwanted merge which would have
further polluted your local master and likely caused merge conflicts
in the future.

So if you follow Andreas's good advice by keeping master "clean"
i.e. purely for tracking origin/master, and doing all your changes on
other branches, you will never have this problem.