Git failed with a fatal error. refusing to merge unrelated histories with git push?

Question

I made some changes locally, which I am trying to push through to github. I have read that I could use '--allow-unrelated-histories' but have only seen examples demonstrating how to do this for pull, which is not what I need. I need to make my local directory be the master.

I tried the following command: git push origin master --allow-unrelated-histories

but it didn't work, I got a message saying that this is an unknown option.

I normally work with visual studio. I got the error there, and I am not fluent at all with git when it comes to the bash. I git bashed to my folder with gitignore files and so on, and tried to do the changes. I would prefer to do this from visual studio if possible really, but I don't know how to modify options from visual studio either.

Edit: Apparently what I want to do is not actually doable. I found that the pull command did 'sort of' what I expected, but not really. I tried changing the username of all commits, to no vain because github will still keep the wrong username. Now every commit is simply doubled with the correct and incorrect username.

Answer 1

Basic tip: pull from clean source , copy changed files ..

on gitlab you have to UNROTECT your master branch ( in settings→repository)

also if your git is too old , the --allow-unrelated-histories might not be implemented , you could do the push --force origin master , but remember that it might mess up not even your repo , also all remote clients might have to pull --force or clone again

See here (long discussion ) Git refusing to merge unrelated histories on rebase

Answer 2

Do you care a lot about preserving your commit history?

If not you could

git reset --soft <commit before it all went to hell>

git status (to check if everything you want is staged)

git commit -m “<commit message>“

git log (to view the commit history and make sure it’s what you want)

git push -f

This will retain the changes you made to local while allowing you to overwrite the remote with the history you just revised.

Answer 3

The --allow-unrelated-histories flag applies only to merging. Since git push does not merge (ever), it has no --allow-unrelated-histories option. (Contrast this with the git pull command, which does sometimes—well, quite often, really—run git merge.)

I tried changing the username of all commits ...

You cannot change anything about any existing commit. All commits are 100% read-only.

What you can do is take a series of commits that have something about them that you don't like—such as the name and/or email address of the author and/or committer—and copy them to new and improved commits that are otherwise the same, but have this issue corrected. It appears that this must be what you did, because:

... [after] the pull command ... every commit is simply doubled with the correct and incorrect username.

This doubling is, of course, exactly what you did when you made corrected commits. You told your Git to discard the old (incorrect) commits in favor of the new improved ones, and it did. But another Git repository—the one over on GitHub—still had, and has, the incorrect commits. You then told your Git to obtain any commits they have, that you don't—which in this case were the commits you'd just discarded—and then join them up with the commits you have that they don't, which in this case are your new-and-improved replacements.

You must discard the joining-up merge, typically via git reset. This gets you back to the situation in which you have replaced your old-and-incorrect commits with your new-and-improved copies—i.e., back to where you were before you ran git pull. You are now back where you were: you still need to convince the Git over at GitHub to discard its old-and-incorrect commits in favor of your new-and-improved ones.

To do that, you must use git push --force or git push --force-with-lease. You must also have permission to do this, though if the GitHub repository is under your control, this is either already the case, or easy to set up (you have to tell GitHub what to forbid, so if you did not forbid yourself from force-push earlier, you need not change anything now).

Note that discarding any given commit necessarily discards all subsequent commits. So if there are additional commits you'd like to keep, you must first copy those to new-and-improved commits, whose improvement is that they append to your existing new-and-improved commits.