What is the proper way of programmatically checking if Git branches can be merged?

Question

I want to test to see if one branch can be merged into another. For example, say I want to test if a release branch can be merged into master, without actually merging into master. I figured I'd do something like this:

#!/usr/env/bin bash
git checkout master
git checkout -b master_temp
git merge my_release_branch

So I figure the merge has succeeded if the exit code is 0, and otherwise the merge failed.

Here is my big concern though: say the merge succeeds, but it opens up the interactive portion. How can I avoid that interactive bit? Sometimes during merges, nano or vim opens and we have to do something (not sure what). Is there a way to turn that off?

This question is basically the same, however, the question does not stipulate that this needs to be done by anything other than a human. In my case, it needs to be automatic/programmatic.

Answer 1

Running git merge will start your preferred editor¹ if and only if all of the following conditions hold:

• The merge starts successfully (i.e., the index is not in a bad state, and the arguments to git merge were all parsed successfully).
• Git found or made a merge base. Older versions of Git will use the empty tree as a merge base for unrelated histories; newer ones require --allow-unrelated-histories.
• The merge base thus found is not the current (HEAD) commit, or you used --no-ff.
• The other commit you passed to git merge is not already an ancestor of the current commit. (For octopus merges, the rules are a little more complicated, but the difference should be clear enough: there is more than one "other commit".)
• The merge succeeded without conflicts, or all conflicts were low-level conflicts resolved via an eXtended-strategy-option (-X ours or -X theirs). (Note that the -s ours strategy never has conflicts, making this constraint vacuous there.)
• You did not pass a -m and merge message argument (or you did but added --edit as well; see commentary below this answer).
• You did not specify --no-commit (the editor is invoked due to the merge commit being made!).

You can therefore guarantee that Git won't run your preferred editor by passing a merge message via -m. Alternatively, you can deliberately not pass a merge message but provide an environment GIT_EDITOR setting that invokes something other than an actual editor. For instance:

GIT_EDITOR=true git merge --quiet $hash

will run the merge to completion without opening an editor, or will fail because the merge itself stopped with conflicts, or never started in the first place. And, as Daniel H noted in comments below, --no-commit suppresses the final commit, hence suppresses the editor.

Besides these techniques, it's possible to invoke git merge-recursive directly. The git stash script does so. Be careful with this trick since it bypasses a lot of the usual safety checks.

---

¹Your preferred editor is defined by the first of these various settings:

• $GIT_EDITOR in the environment
• core.editor as configured through git config
• the compiled-in default editor

Using git var GIT_EDITOR will tell you which editor you have chosen, or defaulted-to.

Answer 2

Late to the party, but you can do this with

git merge-tree $(git merge-base feature_branch master) feature_branch master