debugging data <debugging.data@xxxxxxxxx> writes:
> $ git push origin so-much-foo
> To git@xxxxxxxxxx:user-two/project.git
> ! [rejected] so-much-foo -> so-much-foo (non-fast-forward)
> error: failed to push some refs to 'git@xxxxxxxxxx:user-two/project.git'
> hint: Updates were rejected because the tip of your current branch is behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
>
>
> It doesn't look like the tip is behind though:
>
>
> /project$ git log
> commit dd240b6ba15d27d074726e9b1b0e665e3507a2fd
> Author: User Two <debugging.data+user2@xxxxxxxxx>
> ...
> Date: Mon Nov 24 22:43:08 2014 +0000
>
> file-one.txt with contents "file one"
I do not think anybody can say "It doesn't look like the tip is
behind" by looking only at the above. I am assuming that you are on
your "so-much-foo" branch, but that shows only your state. You are
not inspecting what is actually on the remote branch you are pushing
to, so...
After the failed "git push origin so-much-foo", try "git fetch
origin so-much-foo", which will make the tip of the so-much-foo
branch over there temporarily available in your FETCH_HEAD. And
then do something like:
$ git show-branch FETCH_HEAD so-much-foo
and see how they have diverged. If you want to merge your work with
the updated origin, you can do
$ git merge FETCH_HEAD
after that, or follow the hint given by the failed push, i.e.
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
and do
$ git pull origin so-much-foo
(which by the way can be done without the "git fetch origin ..."
and "git show-branch ..." steps above).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html