Re: push rejected (non-fast-forward)

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: push rejected (non-fast-forward)

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:03:06

debugging data [off-list ref] writes:
$ git push origin so-much-foo
To git@github.com:user-two/project.git
 ! [rejected]        so-much-foo -> so-much-foo (non-fast-forward)
error: failed to push some refs to 'git@github.com: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 [off-list ref]
...
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).

Re: push rejected (non-fast-forward)

From: debugging data <hidden>
Date: 2016-06-15 23:03:07

Thank you Junio.

Do you know how the

    $ git pull origin so-much-foo` 

command manages to keep user-two’s branch up-to-date with remote?

It seems counterintuitive since I am pulling from origin and not explicitly working with remote.
 
Would what you see here been an acceptable scenario?
https://github.com/user-one/project/pull/1

I performed a `git pull` and merged the changes manually. This looks like an awful lot to keep track of, and I’m not sure if it’s acceptable for larger projects.

My goal here is to prepare myself to help out with a large open source project.

Also, if anyone has the patience, would you mind explaining what’s going on here?

$ git show-branch FETCH_HEAD so-much-foo
! [FETCH_HEAD] changed foo/foo.txt contents to "so much foo"
 * [so-much-foo] foo/foo.txt from "so much foo" to "foo\nfoo"
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help