magit-reset-index: Fix typo
magit-reset*: Fix ambiguous argument

When both a revision and a file have the same name,
`magit-reset{,head,soft,hard}' would fail with the following error.

  fatal: ambiguous argument 'NAME': both revision and filename
  Use '--' to separate paths from revisions, like this:
  'git <command> [<revision>...] -- [<file>...]'

Add '--' to all commands to make it clear that the argument is a
revision. (This is already used in `magit-reset-index' and is the same
fix used in commit c5a6cc2577 before the reset functions were
rewritten).
Merge pull request #1508 from kyleam/n/typo

magit-reset-index: Fix typo
Merge pull request #1509 from kyleam/n/fix-ambiguous-reset

magit-reset*: Fix ambiguous argument
magit-rebase{,-interactive}: remove an old trick

Back in the days `magit-rebase' and `magit-rebase-interactive' were
invoked directly, not through the rebase popup.  So we had to make
sure the user did not try to begin rebasing when another sequence
was already in progress.  We don't have to do that anymore.
magit-rebase{,-onto,-interactive}: improve doc-strings
magit-bisect-{good,skip,bad}: move definitions to magit-bisect.el
magit-sequencer-skip: add working implementation

`git cherry-pick' and `git revert' don't actually support the `--skip'
argument which we previously tried to use.  Instead we now do a hard
reset, followed by `git-sequencer-continue'.  This now behaves like
the rebase equivalent `git-rebase-skip'.
Correct debug declaration magit-insert-section.

The two sexp that can be argument of the magit-insert-section macro are
evaluated, and so are form.
Decode path for untracked files.
Test for untracked accentuated file.
Merge pull request #1510 from vanicat/t/untracking-encoding

Decode untracked file name
use selected window to edit rebase sequence

Move the call to `magit-server-visit-args' from
`magit-run-git-sequencer' to `magit-rebase-async'; other
callers of the former don't need to set the visit arguments.

Call `magit-server-visit-args' without providing any values for the
arguments OTHER-WINDOW and ARGS.  Previously we attempted to provide
a value for ARGS, but ended up making OTHER-WINDOW non-nil (which we
don't want) and omitting ARGS (which didn't matter because that value
wasn't used anyway).
use selected window to edit note

Since we do the same for commit messages.  (It might
not look like we so in that case, but we really do).
remove last section gap

Each section, except for the root section, begins with text which
directly belongs to it.  For sections which have children that is the
heading.  Then come the child sections and almost all text that follows
is part of these child sections.  The only exception is that after all
children there may be a single empty line, which serves to separate the
expanded section from its next sibling.  When the section is collapsed
that newline is also hidden.

This is the "newline after children" exception.  Until now there was one
other section: after the headers in the status buffer there was an empty
line separating from the following section which was not part of the
sections that wrap the headers.  It has been like this for a long time
and the reason I did not change it was that I felt that there should be
a separator between the headers and the first non-header section even
when the headers are collapsed (meaning that only the "Head" header is
showing).  I haven't really changed my mind on that but feel that the
elimination of this special case is much more important.  (We could
emulate the old look by adding a separator section after the headers,
which consisted of only a newline).
magit-section-forward: handle "\n after children" special case

There often is a newline after all children which does not belong to
the last child but to its parent.  Iff the parent section is expanded
this newline serves as separator.

When point was on that newline `magit-section-forward' used to go to
the first child instead of the next sibling.
magit-popup-insert-section: ignore maxcols during sequence

This is a kludge on top of another kludge, that's
how these things go.  Needs to be fixed, obviously.
magit-rebase-{edit,reword}-commit: new commands
magit-{sequencer,cherry-pick,revert}-in-progress-p: bugfix

Previously these functions assumed that a cherry-pick/revert is in
progress if ".git/{CHERRY_PICK_HEAD,REVERT_HEAD}" exists.  That does
not have to be the case.  However ".git/sequencer{,/todo} do exist
in both cases, and the content of ".git/sequencer/todo" tells us
which of the two it is.
magit-patch-id: new function