magit-process-password-prompt: support yubikeys
magit-compat.el: whitespace
magit.el: cleanup dependency declaration
magit.el: remove Version keyword
magit-manual-merge: correct doc-string

Also correct indendation.
magit-key-mode-popup-merging: add --no-commit
magit-version.el: properly terminate local vars list

Actually this change is in the Makefile which generates this file.
Makefile: add magit-flow.el to ELS
support aborting a merge action

Suggested-By: Grégoire Jadi <gregoire.jadi@gmail.com>
Revert "magit-key-mode-popup-merging: add --no-commit"

This reverts commit 2d6f9ffca9bc18d4da23e40a522c336d8ad53f60.

Unfortunatly that isn't enough. The various `magit-*-merge'
should be merged into one.
magit-revert-item: replace misleading comment
add magit-run-git*

This new wrapper around `magit-run*' allows removing code
duplicated in the various `magit-run-git..' functions and
other functions.  It behaves like `magit-run*' except that
it also takes care of prepending the `magit-git-executable'
and `magit-git-standard-options'.
magit-git-standard-options: is no longer customizable

`magit-git-standard-options' is now a regular variable not a
customizable option.  It should not be changed by users; it
being a customizable option is asking for trouble.
add magit-run-git-async-with-input

This replaces `magit-run-async-with-input'.
magit-log-edit-commit: cosmetics
Merge branch 'run-git'
add magit-assert-one-parent, replacing magit-choose-parent-id

As before, it is not possible to revert or cherry-pick a merge commit.
That is okay because these are advanced operations with potentially
surprising consequences.  We might support this in the future but it
is not a priority at all.

Unlike before, we don't have a function that does not do what its name
advertises (which used to result in dead code in magit-apply-commit).
magit-apply-commit: remove optional NOERASE argument

Previously when NOERASE was non-nil the output from the previous
`magit-run*' invocation was not removed from the *magit-process*
buffer when calling this function.

The only caller of this function which made use of that argument was
`magit-rewrite-finish-step' (which didn't always use it).

So allso remove `magit-rewrite-finish-step's FIRST-P argument.

Indead, in this case it would make more sense to preserve the previous
output a little longer than in others cases.  On the other hand this is
a kludge which cannot be locally contained.  To keep it would make the
cleanup that follows in the next commits much harder.

(Instead we should make it *always* possible to recover the output of
the last few git invocations.  I would be even better to present that
information in the status buffer, instead of having her resort to the
*magit-run* buffer.  I will address this one way or another eventually.)
split magit-apply-commit into three functions

This basically reverts bded317bc81db781a7454b51a37594304cac2daa which
was horribly misguided.  Let me just say this: it doesn't make sense to
conflate unrelated functions just because they happen to share some
logic.  I guess one could argue that these functions are not completely
unrelated.  Well, it is still much easier (in context of reverting a
commit) to reason about:

  (magit-revert-commit commit)

than

  (magit-apply-commit commit nil nil t)      ; at HEAD~2

- What does reverting have to do with applying?
- What are these arguments?
After jumping to `magit-apply-commit':
- What the &*&$@# is going on here?
- What does cherry-picking have to do with reverting?
- Could it possibly makes sense for the first two optional arguments
  to be non-nil when reverting?
- Since that isn't done anywhere the "reverting" code branch contains
  dead code, or doesn't it?
- Aaaaaaaaaaaaaaaaaaaaaaah!
Merge branch 'split-apply-commit'