Q: Bad behavior when merging into an empty Git repository I'm following Github doc's subtree merges, and I noticed an odd and bad behavior. This is the code (numbered for reference):
#1: git remote add -f <some_dir> <clone_url>
#2: git merge -s ours --no-commit --allow-unrelated-histories <remote_branch>
#3: git read-tree --prefix=<some_dir> -u <remote_branch>

So if you perform this on an existing repository (at least 1 commit), then no problem. Everything is fine, and you can add as many subtrees as you want.
BUT if you made a fresh git init directory and have not committed anything yet, this causes two issues:

*

*The remote repository content is copied once into your base and again into your new <some_dir> (where it should be ONLY), creating a duplication issue.

*When you try to add future subtrees, you may run into a complication wherein #2 fails with a "merge strategy ours" failure message. Removing the -s ours option, it'll tell you a bunch of things (basically your previous subtree and current repo)  will be overwritten.

I'm working around this by checking for the existence of any commit in my sh script (test -z "$(git rev-list -n1 --all)"), but out of curiosity, can someone enlighten me as to what's going on?
