Antoine Pelisse <apelisse@xxxxxxxxx> writes: >>> On Wed, 27 Nov 2013 15:17:27 +0000 >>> Pete Forman <petef4+usenet@xxxxxxxxx> wrote: >>> >>>> I am looking for a way of detecting up front whether a git pull or git >>>> merge would fail. The sort of script I want to perform is to update a >>>> server. >>>> >>>> git fetch >>>> git okay >>>> stop server >>>> backup data >>>> git merge >>>> start server >>>> >> I don't know a simple way to do the pre-merge check without actually >> doing the merge (other than patching git merge to add a --dry-run >> option) > > Wouldn't that be a nice use-case for git-recursive-merge --index-only > ($gmane/236753) ? Possibly, but most of the use-cases for merge --dry-run are better answered by the XY Problem question: Can you step back and explain what the *underlying* goal is? The above sounds a lot like a deployment script, and such scripts are almost always better served by using an actual deployment tool, or failing that, by using some form of checkout -f instead, to ensure that they get whatever they are supposed to deploy. (Using a merge to update is really terrible in the face of non-fast-forward updates, especially when caused by rewriting history to not include some commits.) -- Thomas Rast tr@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html