Merge branch 'master' into stable
release version v2.17.4
Merge branch 'stable'
Merge branch 'doc'
add some more update and status calls to the test-merge script to bounce it around a little and also check that the final state looks sane
typo fix
make shell script executable
Merge branch 'doc'

the new document for resolving merge conflicts is perhaps a little redundant, but it'll do.  and this is probably a reasonably place for thorough and calm reiteration of literal steps if there ever was one.
make merging scenario into a real test
add another test for merging but going the other way.  this actually fails.
throw argument parser errors when in acceptance test paths, those should still fail tests hard
teach `mdm update` a `--strict` option, allowing to fail on hash mismatches.  use it to make a test fail reliably instead of generating warnings.
attempt to throw another wrench in the works by randomly nuking parts of working tree during a merge status, this appears to be fine
start all the merge scenarios with master checked out and deps synced to there
skip the usage hash check on update when in mid merge.  this fixes spurious warnings when using `mdm update` in some merge conflict resolutions.

I'd like to restrict the set of accepted hashes to ones from refs involved in the merge.  But, there's nothing to really say you're wrong if you do a manual merge resolution where you take a new version entirely.  A little wild for my tastes maybe, but I can't tell you it's wrong.  So even that limit might be inappropriate.

Then again, I guess that's a general problem with that warning message.  If you update the gitmodules version spec manually (i.e. without using alter) and use mdm update to fetch that version and then go through the git-add flow to pick up the hash change, you'll get that warning, and in the context of this flow, you know what you're doing, and the warning is wrong.  So that's awkward.

Maybe adding some sort of "--do-changes" flag that says you want to take the changes?  That's out of line, though.  The update command isn't responsible for making changes to the parent repo, ever.  Maybe all this stuff should be in the alter command.  That's a little nerve-wracking in its own way, though, as I have a patch staged right now that would make the alter command simply reject use during states like a merge.  So this will require more thought.
make the copypasta for performing releases more literal about directories.  remove use of = sign, it makes tabcomplete harder for most people.  use a directory instead of a file in the first example, because that's often the first question.
make a note about using a swap space -outside- of the release repo.
manually linewrap the longform explanation of hash mismatch warning emitted by the mdm update command.