0

In some situations while using git you are not able to push your commits due to commits on the remote branch, which you do not have on your local branch. You pull first and sometimes the conflicts are auto-resolved. So, after git pull, you are able to git push.

Why is git not able to resolve this conflict on the remote?

apokryfos
  • 38,771
  • 9
  • 70
  • 114
ingoaf
  • 51
  • 1
  • 8
  • 3
    It is not a conflict, it doesn't even try to merge on push. – tkausl Jan 14 '23 at 09:34
  • So you are saying: if there are commits on the remote which I don't have locally my push will always fail? If yes, is there any particular reason why git works this way and does not auto-resolve when it's possible? – ingoaf Jan 14 '23 at 09:58
  • 2
    Because, if the autoresolve succeeds but is wrong (ie, textual merge works but the code makes no sense), there would be no easy way to recover to a good state. Also it would still leave your local branch out of sync with the upstream. – Useless Jan 14 '23 at 10:06

1 Answers1

0

I believe you are conflating diverged branches with resolving conflicts, when in fact they are two entirely different concepts. You have additional questions in a comment which I think will make it easier to answer your overall question:

if there are commits on the remote which I don't have locally my push will always fail?

Yes, a regular push (git push) will always fail if your local and remote branch have diverged. The reason for this is your push will blow away some commits on the remote branch, and normally you don't want to do that by accident. When you're diverged, you typically will do one of these:

  1. Bring those commits into your branch (for example by using pull, merge, rebase, etc).
  2. Tell Git, "Yes, I know I'm diverged, and I do in fact wish to blow away those commits." This is accomplished by using a force push (git push --force). Note that force pushing with --force is rarely the correct choice, and instead you should use some optional safety checks such as --force-with-lease and --force-if-includes. More info here and here.
  3. Decide you like the remote branch better than your own and just replace your local branch with the remote branch. (e.g. git reset --hard @{u})

Now it may be easier to answer your other question about conflicts:

If yes, is there any particular reason why git works this way and does not auto-resolve when it's possible?

I think at the time you asked the question your assumption was that when you're diverged, you would choose option #1 above. Git can't know that's what you want to do and therefore Git won't try to perform the merge for you, when you push.

There are ways to perform remote merges, and these are typically called "Pull Requests" or "Merge Requests". Note those are add-on features provided by Git SCM tools and are not natively part of Git.

Even in the concept of Pull Requests though, very view tools will attempt to resolve conflicts automatically. One way to think about it is that a "conflict" is a merge that Git can't (or won't) resolve automatically, without further instructions. It's possible to provide further instructions when performing merges locally, such as "when there's a conflict, use my/their change". AFAIK those options are not available for Pull Requests though on the remote.

That being said, perhaps you could have asked something like,

When pushing and your branches are diverged, if a merge could be performed automatically, why doesn't Git just do the merge for you?

And the answer to that question, as hinted to above, is simply that "that's not how push works". In theory, an option could be created to do it, for example something like, git push --merge, but given how easy (and sometimes necessary) it is to just do the merge locally instead where you have full control, I'm not sure that an option like that would ever be implemented. Furthermore, it doesn't really make sense to create commits on a remote in a DVCS anyway, and if it did, the next thing you'd have to do is pull since you'd be out of date.

By the way, you're not the first person to wonder this, as a similar question was asked before.

TTT
  • 22,611
  • 8
  • 63
  • 69