Error on moving a GitHub repository into another repository

Question

I have a GitHub repository funfun with a long history. I have another GitHub repository TBD.

Now I want to move the folder funfun under the folder TBD, then from now on I will only work on the repository TBD. I want the commit history of funfun to be kept.

I followed this solution. Here is the result:

MBP:TBD$ ls
OCaml       README.md
MBP:TBD$ git remote add funfun ../funfun
MBP:TBD$ git fetch funfun --tags
warning: no common commits
remote: Counting objects: 11874, done.
remote: Compressing objects: 100% (4286/4286), done.
remote: Total 11874 (delta 9020), reused 9813 (delta 7494)
Receiving objects: 100% (11874/11874), 21.98 MiB | 20.68 MiB/s, done.
Resolving deltas: 100% (9020/9020), done.
From ../funfun
 * [new branch]      master     -> funfun/master
MBP:TBD$ git merge --allow-unrelated-histories funfun/master
warning: Cannot merge binary files: .DS_Store (HEAD vs. funfun/master)
Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md
Auto-merging .DS_Store
CONFLICT (add/add): Merge conflict in .DS_Store
Automatic merge failed; fix conflicts and then commit the result.
MBP:TBD$ git remote remove funfun
MBP:TBD$ ls
Addins          bin         package-lock.json   units
OCaml           config          package.json        views
README.md       git.sh          public          webpack.config.js
addin           models          routes
app.js          output.csv      ssl

When I look at TBD on the website of GitHub, funfun was not added.

Is it because of Automatic merge failed; fix conflicts and then commit the result.? Does anyone know how to fix it?

PS: either having a subfolder TBD\funfun\ or putting all the subfolders of funfun under TBD (as above) is fine, I can always arrange folders afterwards.

Answer 1

You have done most of the work. Now it's just about fixing the merge conflicts. Lets tackle it one by one.

CONFLICT (add/add): Merge conflict in README.md

This one is pretty straighforward. The README.md file has some conflict(s), which you can manually fix by editing the file and saving whatever is required in it. Make sure that you remove the lines with <<<<<<<, ======= and >>>>>>> in it which are used by Git to show the conflict. Onto the next one.

CONFLICT (add/add): Merge conflict in .DS_Store

The .DS_Store is created on Mac and you can view that by running ls -a, and should usually be ignored from source control by adding it to the .gitignore file at the root of the repo directory. Since it hasn't been done already, the conflict is occurring with that file too. So now you should first remove all occurrences of .DS_Store from your repo directory by running the below command at the root of the repo directory:

find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch

Next, if you have a .gitignore file already, add a line with .DS_Store to the same. Otherwise, create and add the entry by the command at the root of the repo directory

echo .DS_Store >> .gitignore

Next just commit the changes with the usual

git commit -am "Commit message"

Then push the changes with

git push origin master

Work done!

Answer 2

Looks like the merge conflicts are the issue. Both folders had a README.md file, so they caused a conflict. Pick which one you want to retain and that should work. Your merge didn't complete due to the conflicts (that's what it means by "fix conflicts and then commit the result.") so things diverged from your instructions there.

The .DS_Store file is a hidden file create by Mac OS X. I'm assuming you're doing this on a mac? It doesn't show up in your ls because it starts with . (interpreted as a hidden file). The quick fix is to remove it from your destination directory before you try the merge so it doesn't create a conflict.

The slightly longer version is that you usually don't want to check those files in to a git repo in the first place. It's pretty common to include .DS_Store in a .gitignore file and check the ignore file into the repo so that git doesn't track it. Now that the file is already checked in you'll still have to remove them from the repo before the merge, though.