Find source of mistake: git push rejected: error: failed to push some refs

Question

In one of the teams, when working with git, again and again we run into "git push rejected: error: failed to push some refs"

To [email protected]:ledy/thakres.git ! [rejected]
b_stable -> b_stable (non-fast-forward) error: failed to push some refs to '[email protected]:ledy/thakres.git' To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes (e.g. 'git pull') before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details.

Of course, we can continue with "-f" as quick'n'dirty - not really a - solution.

However, we'd like to know where this comes from or what's the reason for this rejection.

Can't git give verbose details about the reason why it's rejecting, maybe the file which is causing the conflict?

We have a suspect on .gitignore which was causing similar issues on another project.

Solution 1

Git doesn't push individual files one at a time, it pushes complete commit trees, as in, "here is how the entire project looked at one commit, and then it looked like that at another, and now finally it looks like this".

Drawn as a graph of commits, this is, e.g., the very linear:

...--D--E--F--G    <-- master

What's being "rejected" is that the "finally" you're supplying is not "forward progress" from the "finally" the remote had before, i.e., you're missing some "forward progress" that someone else put in. You had:

...--D             <-- master

and then you added commits E, F, and G. But while you were doing that, someone else picked up the series of commits ending in D and added his or her own commit H:

...--D--H          <-- master

You're proposing to throw away H and make the commit sequence look like your sequence: D is followed by E-through-G and that's the end of everything.

Git tells you the branch name that has the progress you're proposing to throw away, in this case, master. It's up to you to git fetch the progress and then retain it, perhaps by git merge creating a merge commit M:

       H------
      /       \
...--D         M   <-- master
      \       /
       E--F--G

or perhaps by "rebasing" your series of commits on top of H:

...--D--H-E'-F'-G' <-- master

(where E', F', and G' are versions of "what changed in E, F, and G" with just enough changed to make them apply on top of H instead—quite often that's just commit parentage, occasionally there's a bit more work involved).

Solution 2

Do a git pull, then try to push, that's what the message is saying.

Comments

[ledy]

first of all, thanks for the detailled explanation. anyways, how to analyze the exact source of mistake at this point? Can't git tell me, which part of the tree is missing or give a hint where this can be found exactly? In the history, I see no other one than me who added a commit to the master. they added their changes into several branches different from master. however, if they are updating b_stable and I try commit and push to master, this conflicts with notice about b_stable <- that i did not care about...

[torek]

As above, you have to use git fetch to pick up "their" commits. You should set up a "remote" that names the URL and provides a name-space to track "their commits". If your repo was cloned from [email protected]:ledy/thakres.git originally it already has a remote named origin that points there. Then git fetch origin will bring over all necessary commits and update origin/master to denote them. Use git log origin/master or gitk --all to view "their" commits and decide what to do. If it's just git merge, you can use git pull; see other SO posts.

[torek]

Also (ran out of space): git push can take a branch name; git push origin master limits the push to pushing just the master branch to remote origin. (Eventually you may want to decide what to do about b_stable too but that can be later.) This is probably what you want for the moment.

[ledy]

please correct me if i am wrong; but this git fetch will overwrite my own changes, doesn't it?

[torek]

No, the nice thing about git fetch is that (with normal setups) the only thing it does is add new commits under the refs/remotes name-space. This lets you see what other people did, but does not touch any of your own branches, which are under the refs/heads/ name-space. (The "remote branch" origin/master is really refs/remotes/origin/master, in that other name-space.)

[ledy]

git fetch and git fetch origin runs without any action or modification. empty output, nothing to do... finally, it's still rejecting when pushing again. Also, git status is telling me that there is nothing different, not in master, not in b_stable. Though, push is rejected. Although I could easily skip this with -f, I'd really be glad to fix instead of force and find out why this is happening again and again.

[ledy]

This does not resolve the issue. As described, with -f it can be forced and overwritten, but that's not a fix or detail on the source of mistake that I am looking for.

[torek]

I suspect you have a b_stable that is not set to track origin/b_stable, and/or some interesting push configuration items. What does git config --get-regexp '^branch\..*' show, for instance?

[Jorge Orpinel Pérez]

Yes but read @torek's answer that explains about branches. May need to checkout the appropriate ones first.