Marcel 'childNo͡.de' Trautwein" wrote:
> I think we have a problem … or at least I had
> and I’m not quite sure if this is „working as designed“
> but I’m sure it „should not work as it did“.
> I wanted to clone another repository … but yeah … it’s late for me today and
> I put
> in s.th. `git pull
> next … all committed files are zapped and the repository given has
> been checked out in my home directory 🤯👻
> what? Shouldn’t this just fail? Why can I pass another remote to pull?
Sorry, this is not the most helpful reply but:
Can you describe a reproduction recipe so that I can experience the
1. steps to reproduce
2. expected result
3. actual result
4. the difference and why it was unexpected
I suspect that this information is in your message, somewhere, but it
is (understandably) unfocussed and I am having trouble pulling it out.
> trying to fix this up by doing another pull failed:
> -bash:$ git remote -v
> origin g...@bitbucket.org:childnode/marcel.git (fetch)
> origin g...@bitbucket.org:childnode/marcel.git (push)
> -bash:$ git pull
> fatal: refusing to merge unrelated histories
Ok, this part is something I might be able to help shed some light on.
Searching for 'unrelated' in "git help pull" finds:
By default, git merge command refuses to merge histories that do not
share a common ancestor. This option can be used to override this
safety when merging histories of two projects that started their
lives independently. As that is a very rare occasion, no
configuration variable to enable this by default exists and will not
So that explains the "what" of that error message.
The "why" is a separate question. Could you share output from
git log --all --graph --decorate --oneline --simplify-by-decoration
to help us understand your current state?
Also, suggestions for improvements to the 'refusing to merge' message
would be very welcome.
Thanks and hope that helps,