Fatal: Refusing to Merge Unrelated Histories

fatal: refusing to merge unrelated histories

I get this error every now and then. This happens when I created a new branch first right after a new Git project was started (by me), without bothering to base it from the Master branch. The reason is the lack of permission/access to being able to write or put anything on the latter branch.

Rather than waiting for someone to kick off the Master branch, I just go ahead and start my own branch as I’ve mentioned earlier. Later on, somebody from the team who has write permissions to Master, starts a README file just to initiate it. Thus the “unrelated histories” issue happens from then on. Two branches that started off independently from each other and with no common base.

The issue appears when I want to merge my branch to Master. Git will say my branch is behind on commit on the branch it will be merged into. If I try to merge it, it gets rejected. The pipeline also won’t allow for merge conflicts like this, and advises me to fix it first.

ANSWER

As I recall, this behavior started after a certain Git version only. This to avoid to unnecessarily create a parallel history being merged into the project, because a previous merge happened between to branches that didn’t have a common base.

I’ve used Git’s “–allow-unrelated-histories” option to fix this problem. I’ll do this via command line.

Pull the Master branch into mine with the option above included.

Fix the merging conflict.

Commit the changes.

Push to remote repository.

Then this time the merge request to Master will not warn that my branch is behind a commit.

Others have commented saying that rebasing also does the trick for them. I do not recall having gone that route though.

How do I map commits from a DVCS to the actual version numbers?

When using a centralized version control system such as SVN, where every commit acquires an auto-incremented number, it is relatively easy to track what version is released to production by simply setting the version to the identifier of the commit. Version 2.4.0.18522, for instance, matches the 18,522th commit.

With distributed version control systems such as Git, however, the identifiers are hashes, rather than numbers. I can hardly imagine someone on the phone saying: “There is a regression in our version 2F90C275A,” and non-numeric versions don’t play well with some tools, which means that versions are dissociated with the commits: commit 2F90C275A may become version 2.4.0.15, “15” here being the value of an auto-incremented counter in the build tool.

In practice, I find it particularly challenging to find which is the commit of a particular version, and I need to know the mapping to be able to answer a bunch of questions, such as:

  • “Is [a given change] that was committed last Friday morning part of the version 2.4.0.15?”
  • “What could have broken [a given feature] in version 2.4.0.15?”
  • “Let’s do a hotfix. From which commit exactly should we create the hotfix branch?”
  • etc.

If one imagines that the build is done in a way that virtually any commit from the origin/master can be pushed later on to production, how am I supposed to manage versions properly in order to be able to easily see which version maps to which commit and vice versa?

Go to Source
Author: Arseni Mourzenko