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 is reproducable build guaranteed with version ranges in NPM

I know with npm, caret and tilder and some logical operators can be used to specify version ranges. This post explains a bit on how this works.

The problem now is I find it hard to rectify the use of version ranges with the idea of having reproducible builds.

I mean version ranges for dependencies means that you are not specifying a requirement for a particular version but a range of version, which might change between builds (ie a patch release of a dependency was released between the last and current build).

Reproducible build seeks to remove variability in environment ensuring that every repeated build would always be the same.

From where I stand, these two ideas are in conflict with each other, hence my question here: perhaps someone can help me understand how it is ever possible to have reproducible builds with version ranges when using npm

Go to Source
Author: Finlay Weber

What can be used as abbreviation for perpetual beta?

According to Wikipedia, we talk about stages of development;

  • prealpha
  • alpha
  • beta
  • release candidate
  • stable

But, beta also have 2 sub-stages;

  • perpetual beta
  • open/closed beta

Now if we were to version a software with these and semver. It would look somewhat like this:

  • prealpha: 0.x.x
  • alpha: x.0.0-alpha.x
  • beta: x.0.0-beta.x
  • release candidate: x.0.0-rc.x
  • stable: x.x.x

However how would these look if we want to differentiate between perpetual and open/closed beta?
Would this be allowed, and if yes would something like this work?

  • perpetual beta: x.0.0-pb.x
  • open/closed beta: x.0.0-ob.x, x.0.0-cb.x

Go to Source
Author: Keimeno