Git Merge commits into an orphan branch

Question

I'm curious to know if you CAN and if there is anything wrong with merging commits INTO my orphan branch. For this specific instance my Salesforce repository has a master branch and a pre-release branch but because our sandbox environment often has metadata that is not part of production yet we want to version control it but separate enough from our clean pre-release branch.

So as it is we have the following:

(Production Init Commit)    (official release)
 /                         /
o-------------------------o [master]
 \                       /
  o------o---------o----o [pre-release]
          \       /
           o-----O [feature]
                  \ <-- IS THIS ALLOWED/POSSIBLE/BAD IDEA?
                   \ 
       o------------O [DEV] (orphan branch)
      /
     (Initial commit from our sandbox environment)

Answer 1

Merging commits that do not have a common root commit is allowed with Git. The result will contain the union of the files present in both branches. This is a common practice to merge two projects into a single repository (for example, the Git project itself was started at e83c51633, gitk was started at 1db95b00, and both projects were merged later at 5569bf9bb).

Now, whether you actually want to do that really depends on the content of branches. If you merge your sandbox branch into your feature branch, then merging your feature branch into master will also bring your sandbox code into master, which you probably don't want.

Answer 2

With git 2.9 (June 2016), merging orphan branches is still possible, but ony with the --allow-unrelated-histories option:

git merge --allow-unrelated-histories a b

See commit e379fdf (18 Mar 2016) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit d04aa7e, 08 Apr 2016)}

merge: refuse to create too cool a merge by default

While it makes sense to allow merging unrelated histories of two projects that started independently into one, in the way "gitk" was merged to "git" itself aka "the coolest merge ever", such a merge is still an unusual event.
Worse, if somebody creates an independent history by starting from a tarball of an established project and sends a pull request to the original project, "git merge" however happily creates such a merge without any sign of something unusual is happening.

Teach "git merge" to refuse to create such a merge by default, unless the user passes a new "--allow-unrelated-histories" option to tell it that the user is aware that two unrelated projects are merged.

Because such a "two project merge" is a rare event, a configuration option to always allow such a merge is not added.

The git merge doc mentions:

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 be added, and the list of options at the top of this documentation does not mention this option.
Also git pull does not pass this option down to git merge (instead, you git fetch first, examine what you will be merging and then git merge locally with this option).

---

See commit de22496 (21 Apr 2016) by Junio C Hamano (gitster).
^{(Merged by Junio C Hamano -- gitster -- in commit 175008d, 29 Apr 2016)}

pull: pass --allow-unrelated-histories to "git merge"

Instead of:

git fetch something &&
git merge --allow-unrelated-histories FETCH_HEAD

If somebody is inclined to add such an option, updated tests in this change need to be adjusted back to:

git pull --allow-unrelated-histories something