Thomas Rast <tr@xxxxxxxxxxxxx> writes: > 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.) It is a deployment script and updates are fast-forward. There was a problem on a test server where a file had been hacked to investigate an issue. The next deploy failed with the merge error. There are three approaches, which might all be done with git or an actual deployment tool. 1. test early, bail out if deploy would fail 2. set target to good state before applying the merge 2a. discard changes 2b. stash changes I intend to use (1). First I will need to clean up the stray files or add more entries into .gitignore. test -z "$(git status --porcelain)" -- Pete Forman http://petef.22web.org/payg.html -- 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