1

Please note my question is not "what should i do ?", because i have already read other questions on stack overflow. I know i have to give --allow-unrelated-histories parameter.

My question is "why".

Here are operations i have done with git version 2.17.0.windows.1. Please note this error do not happen with git version 2.7.4 on Linux:

I first create an empty repository on gitlab. Then, i have 2 users, on 2 different computers:

First user:

git clone <repository_url>
cd myproject
touch file1.cpp
git add file1.cpp
git commit -m "file 1 creation"
git push origin master

Second user:

git clone <repository_url>
cd myproject
touch file2.cpp
git add file2.cpp
git commit -m "file 2 creation"
git pull

At this time, i have this error message:

fatal: refusing to merge unrelated histories

I do not understand WHY i have this error message on git windows version and not on Linux...

Thanks

Bob5421
  • 7,757
  • 14
  • 81
  • 175
  • 1
    The 1st user didn't push nor pull. That means they're isolated from everyone else, so they're irrelevant. That just leaves the 2nd user. That could happen if someone else radically altered the repository's history. Could you show us `git log --oneline --graph --decorate` for the second user? You're looking for something like `master` and `origin/master` having no connections to each other. – Schwern May 27 '18 at 17:50
  • Sorry i have made a mistake. First user is pushing. I have added the missing line – Bob5421 May 27 '18 at 17:53
  • Still shouldn't have that effect. `git log --oneline --graph --decorate --all` will be very useful. – Schwern May 27 '18 at 17:54
  • 2
    This might help. https://stackoverflow.com/questions/37937984/git-refusing-to-merge-unrelated-histories-on-rebase Note that you're using 2.17 and 2.7, right across the 2.9 line when this changed. – Schwern May 27 '18 at 17:56

1 Answers1

5

I first create an empty repository

That’s where the issue is. An empty repository has no commits, so when each user does git commit after pulling the empty repository, they are creating the one-and-only root commit. As such, when one pushes and the other tries to pull (already having made another root commit locally), Git complains because the upstream shares no commits with the local copy. They are two completely different, unrelated histories.

You can avoid this by ensuring an initial commit is created and pushed before anyone else pulls (so everyone has the same root commit), or by using --allow-unrelated-histories to bypass the error as you’ve mentioned. Personally, I think the first option is better.

As for why the discrepancy between the two Git installs: as @Schwern commented, this behavior was added in Git 2.9.

Andrew Marshall
  • 95,083
  • 20
  • 220
  • 214
  • 1
    Great observation! I'll note that a better solution than `--allow-unrelated-histories` is to always use `git pull --rebase=preserve`. This replays your local work on top of the remote as if you'd written your changes on top of the latest version all along. This will seemlessly deal with situations like the above, or the more common case where the upstream branch has been rewritten. It also keeps history tidy by avoiding a lot of meaningless "update" merges. You can set this in your config `git config --global pull.rebase preserve`. (I had trouble reproducing the problem because I had it set.) – Schwern May 27 '18 at 18:14
  • Is it possible to create a first commit, with no file ? – Bob5421 May 27 '18 at 19:21
  • @Bob5421Yes, pass [`--allow-empty`](https://git-scm.com/docs/git-commit#git-commit---allow-empty). – Andrew Marshall May 27 '18 at 20:03