In my case, the error was just fatal: refusing to merge unrelated histories on every try, especially the first pull request after remotely adding a Git repository.

Using the --allow-unrelated-histories flag worked with a pull request in this way:

git pull origin branchname --allow-unrelated-histories

As per 2.9.0 release notes - git pull has been taught to pass the --allow-unrelated-histories option to underlying git merge

I ran into a similar problem where I brought in a branch from a second remote and wanted to merge with a branch from the first remote. This is different from the existing answers as I'm not using --allow-unrelated-histories on the pull, but on the merge.

git fetch origin main
git checkout main
git merge --allow-unrelated-histories myfunnybranch

This fetches and checks out the main branch and merges the myfunnybranch into it. By using git fetch rather than git pull we distinguish between bringing code to our machine, and performing the difficult merge.

When NOT to perform an unrelated history merge

Warning: An "unrelated history" is a history that does not go back to a common source. In other words, myfunnybranch and main are derived from two completely different repositories.

If the two repositories are very similar or have lots of files in common, there is a good chance that one of the repos lost its history somewhere along the way. Whether or not this is the case, its probably best to avoid two histories leading to the same set of files. Instead, you'd like to keep the longer history and have a single commit bringing in any changes from the other repository. To achieve this goal, checkout the repository with the longer history and copy the files of the other one in, which should produce a small commit with few changes, which git status and git diff will summarize for you before you make the commit with git commit. For more details, this answer to another question, which was mentioned in a comment on another answer to this question.

In the OP's case (which was elaborated on in an edit to the question), there is likely no need for an unrelated merge. Perhaps the OP didn't clone the repo, or perhaps someone else pushed to the empty repo before the OP made their initial commit. Either way, since the OP is editing only a single file, it would be better to simply clone the repo fresh, copy the new file into the cloned repo, and add, commit, and push there.

When TO perform an unrelated history merge

You would only want to merge unrelated histories if the two repositories indeed share very little in common. For example, each repository contributes a different set of files during the merges.

In my case I wanted to merge two totally different repos that had files in different directories and I wanted to preserve the history of both of these. This was code that I thought should be together in a single repo but was originally written in two different repos.

While the OP appears to be adding a new file here, this is probably not a case where we need multiple histories.

As P. Ent notes in a comment, one case where it makes sense to merge unrelated histories is when you have performed a fair bit of development locally, and there really hasn't been much development on origin/main. If essentially all of the development was done locally on myfunnybranch, it might even make sense to run

git checkout myfunnybranch
git merge -s ours --allow-unrelated-histories main

This ignores all the work on the main branch, but keeps it in the history. Only the code in myfunnybranch is kept. Now merging myfunnybranch back into main should be easy.

In cases like these, git log --all --graph is useful to see what your local repository looks like before you push anything.

For example, after the git merge -s ours command suggested above, you might find your repo to look like

git log --all --oneline --graph
*   6c8188b (HEAD -> myfunnybranch) Merge branch 'main' into myfunnybranch
|\
| * b93aabd (origin/main, origin/HEAD, main) Initial commit on remote server
* f69e99b some work I did locally
* df5d8ae more local work
* da455d6 Initial commit that I made locally

In this case you could use

git diff 6c8188b f69e99b 

to confirm that your most recent commit, 6c8188b, really didn't change any of the work you did locally. It will print nothing if there are no changes.

Then, merging myfunnybranch back into main will result in main matching your local development, too. This is because from the main branch's perspective, commit 6c8188b makes a whole bunch of edits bringing the branch exactly in line with the other branch.