rebase -i: remove no-op do_with_author git commit --amend

The author script is a file in the state directory that contains
assignments of the environment variables

    GIT_AUTHOR_NAME
    GIT_AUTHOR_EMAIL
    GIT_AUTHOR_DATE

to be evaluated by the shell. It is used to store author information
and has two applications in `git-rebase--interactive.sh`. Firstly,
the authorship of squash commits is read from it while the squash
commit is being amended step by step. Secondly, after conflict
resolution `git rebase --continue` restores the author information of
the original commit by sourcing the author script. For the
assignments of the git environment variables to take effect,
git-rebase--interactive executes the respective git-commit commands
wrapped in `do_with_author`. That shell function executes the named
command in a subshell that exports the git environment variables.

Since

    git commit --amend

has been used instead of

    git reset --soft HEAD^
    git commit

to amend squash commits, wrapping git-commit in `do_with_author` has
become a no-op because, unless the `--reset-author` option is
specified, `git commit --amend` ignores the user environment and
reuses the authorship of the commit it amends. To make the code
clearer and until we decide to use other authorships for squash
commits than the one of the first commit, unwrap `git commit
--amend`.
squash! rebase -i: teach do_pick the option --reset-author

rebase -i: teach do_pick the option --reset-author

`do_pick` is the git-cherry-pick wrapper in git-rebase--interactive
that is used to implement many of the to-do list commands.
Eventually, the complete `do_pick` interface will be exposed to the
user in some form or another and those commands will become simple
aliases for the `do_pick` options now used to implement them.

Add the git-commit option `--reset-author` to the options pool of
`do_pick`. It rewrites the author date and name of the picked commit
to match the committer date and name.

If `--reset-author` is passed to `do_pick`, set the `rewrite` flag
and relay the option to the git-commit command line which creates the
final commit. If `--amend` is not passed as well, the fresh
authorship effect is achieved by the mere fact that we are creating a
new commit. Do not even source the ident information in that case
because the user shell might have already exported the respective
environment variables.
rebase -i: do not overwrite user author information

The shell function `get_author_ident_from_commit` defined by
git-sh-setup retrieves the author information from the named commit
and returns assignments of the environment variables

    GIT_AUTHOR_NAME
    GIT_AUTHOR_EMAIL
    GIT_AUTHOR_DATE

ready for evaluation by the shell.

This interface is used in conjunction with the so-called author
script which is a git-rebase--interactive state file that contains
the `get_author_ident_from_commit` output. It is sourced when `git
rebase --continue` is executed after conflict resolution to retain
the original commit authorship.

The variable assignments are only exported by the subshell that
executes the git-commit command line that commits the resolved
conflicts. That is taken care of by wrapping the git-commit call in
`do_with_author`. However, this is not enough protection from
modifying the git environment variables unintentionally because the
user running git-rebase could have already exported those herself.
And therefore, a bare git-commit could result in an authorship that
is neither intended by the user nor by git-rebase--interactive.

While it is not an issue now (either `do_with_author`,
git-cherry-pick or `--amend` are used to create commits), the
unnecessary loss of the author name and e-mail copied from the user
environment, and the unneeded fixing of the author date might become
a problem when we decide to support something similar to
`--reset-author` or `--ignore-date in interactive git-rebase.

Do not assign the git environment variables until in the
`do_with_author` subshell.
rebase -i: refuse to commit when resuming with updated head

If git-rebase--interactive fails to apply the changes introduced by a
commit due to conflicts, it interrupts the rebase process and gives
the user a shell to resolve the conflicts manually. The process is
resumed when the user executes `git rebase --continue`. If the index
has changes, the script assumes that those are to be committed under
the authorship and with the log message of the commit it tried to
replay last. However, that assumption is most likely incorrect if the
user has already committed the resolved changes herself. To prevent
committing unrelated changes under the wrong authorship and with the
wrong log message, at least check that HEAD is still at the same
commit by tracking the hash of the last replayed commit. A similar
check already happens before `git rebase --continue` amends the
previous commit after an `edit` or a conflicted `squash` command.
squash! rebase -i: enable options --signoff, --reset-author for pick, reword

rebase -i: enable --signoff, --reset-author for pick, reword, edit

Lift the general unknown option blockade for the `pick`, `reword` and
`edit` commands. If `do_cmd` comes across one of the options
`--signoff` and `--reset-author` while parsing a to-do entry and the
scheduled command is either `pick` or `reword`, relay the option to
`do_pick`.

Remember to add Signed-off-by: and to reset the authorship even when
the rebase is interrupted for conflict resolution and `git rebase
--continue` creates the commit. Employ the same mechanism that is
used to remember amending an interim squash commit after conflict
resolution or a commit after editing. If a line option was specified,
create the files `signoff` and `resetauthor` respectively in the
state directory. While `signoff` is handled by simply specifying the
`--signoff` option when creating the commit, the `resetauthor` case
is somewhat more involved. The author script contains the author
information of the replayed commit. Renewing the authorship means
using the user environment for the authorship so that we need to skip
the author script if `resetauthor` exists and we are not amending. If
we are amending, `--reset-author` must be passed to git-commit
because otherwise the authorship of HEAD would be used.

`do_pick` options like `--gpg-sign` and `--file` are not yet
supported because `do_cmd` cannot handle option arguments and options
with spaces at the moment. `squash` and `fixup` still do not accept
user options as the interplay of `--reset-author` and the author
script is yet to be determined.

Document the new options by listing them in the to-do help and giving
a usage example in the "INTERACTIVE MODE" section of the git-rebase
man page.

Add tests.
fixup! rebase -i: allow rewording empty commits without complaints
squash! fake_editor: leave standard output unchanged

fake_editor: leave standard output unchanged

The helper function `set_fake_editor` installs a script as
`GIT_EDITOR` that applies pre-defined editing rules to the files it
is called with, which is a quite powerful tool when writing test
cases for git-rebase--interactive. To aid in debugging the changes it
makes, the installed script dumps the file contents to stdout before
and after editing. That interferes with the output from
git-rebase--interactive, however, and the debug information has to be
removed from stdout in a error-prone way. Print the editor contents
on stderr instead.

When a test case wants to analyse stderr, we need to come up with a
different solution. The less convenient possibility that always
remains is to store the debug output in a file in the "trash"
directory or even keeping copies of the edited files before and after
editing.
fake_editor: leave standard output unchanged

The helper function `set_fake_editor` installs a script as
`GIT_EDITOR` that applies pre-defined editing rules to the files it
is called with, which is a quite powerful tool when writing test
cases for git-rebase--interactive. To aid in debugging the changes it
makes, the installed script dumps the file contents to stdout before
and after editing. That interferes with the output from
git-rebase--interactive, however, and the debug information has to be
removed from stdout in a error-prone way. Print the editor contents
on stderr instead.

When a test case wants to analyse stderr, we need to come up with a
different solution. The less convenient possibility that always
remains is to store the debug output in a file in the "trash"
directory or even keeping copies of the edited files before and after
editing.
squash! rebase -i: hide interactive command messages in verbose mode

rebase -i: hide interactive command messages in verbose mode

git-rebase--interactive prints summary messages of the commits it
creates in the final history only if the `--verbose` option is
specified by the user and suppresses them otherwise. This behaviour
is implemented by wrapping git-commit calls in a shell function named
`output` which redirects stderr to stdout, captures stdout in a shell
variable and ignores its contents unless the command exits with an
error status.

The command lines used to implement the to-do list commands `reword`
and `squash` print diagnostic messages even in non-verbose mode. The
reason for this inconsistency is that both commands launch the log
message editor `GIT_EDITOR` which usually requires a working terminal
attached to stdin. Wrapping the `reword` and `squash` command lines
in `output` would seemingly freeze the terminal (see commit 7725cb5,
"rebase -i: fix reword when using a terminal editor"). Temporarily
redirect the `GIT_EDITOR` output to a third file descriptor in order
to ship it around the capture stream. Wrap the remaining git-commit
command lines in the new `output`. At the moment, it is still no
alternative to pass the `--quiet` option in non-verbose mode because
git-merge-recursive for instance prints some messages regardless of
the verbosity level.

In order to temporarily redirect the editor output, the new
definition of `output` creates a wrapper script in the state
directory to be used as `GIT_EDITOR`. Make sure the state directory
exists before `output` is called for the first time.
squash! rebase -i: root commits are replayed with an unnecessary option

rebase -i: do not use -C when --no-edit is sufficient

The command line used to recreate root commits uses `-C` to suppress
the log message editor. This is unnecessarily confusing, though,
because that suppression is a secondary effect of the option. The
main purpose of `-C` is to pull the metadata from another commit, but
here we know that this is a no-op, since we are amending a commit
just created from the same data.

At the time `-C` was introduced, git-commit did not yet have a
documented `--no-edit`, and this was a reasonable way to get the
desired behavior. Switch it to use `--no-edit` to make the intended
effect more obvious.
squash! rebase -i: failed reword prints redundant error message

rebase -i: discard redundant message when rewording fails

The to-do list command `reword` replays a commit like `pick` but lets
the user also edit the commit's log message. If the edited log
message is empty or is found ill-formatted by one of the commit
hooks, git-rebase--interactive prints three error messages to the
console.

    1. The git-commit output, which contains all the output from hook
       scripts.
    2. A rebase diagnosis saying at which task on the to-do list it
       got stuck.
    3. Generic presumptions about what could have triggered the
       error.

The third message contains redundant information and does not add any
enlightenment either, which makes the output unnecessarily longish
and different from the other commands' output. For instance, this is
what the output looks like if the log message is empty (contains
duplicate Signed-off-by lines).

    (1.) Aborting commit due to empty commit message. (Duplicate Signed-off-by lines.)
    (2.) Could not amend commit after successfully picking fa1afe1... Some change
    (3.) This is most likely due to an empty commit message, or the pre-commit hook
         failed. If the pre-commit hook failed, you may need to resolve the issue before
         you are able to reword the commit.

Discard the third message.

It is true that a failed hook script might not output any diagnosis
but then the generic message is not of much help either. Since this
lack of information affects the built-in git commands for commit,
merge and cherry-pick first, the solution would be to keep track of
the failed hooks in their output so that the user knows which of her
hooks require improvement.
squash! rebase -i: squash skips commit-msg hook

rebase -i: verify squash messages using commit-msg

Using the to-do list command `squash` the user can specify two or
more commits and git-rebase creates one commit that introduces all
their changes combined. The authorship for the created commit is
taken from the first commit specified and the user can edit the log
message. There is a variant of `squash` available named `fixup` which
also takes the first log message without asking for user input.

While it is reasonable to not verify replayed changes twice or
rejecting some other author's changes in her name, it is insufficient
to not verify the user input used as log message in the case of
`squash`. Specify the git-commit option `--no-pre-commit` instead of
`--no-verify` when committing the squash result, but not before, to
let the commit-msg hook verify the final squash message. For the same
reasons the pre-commit hook is disabled in all replay modes, the
commit-msg hook is disabled in `fixup` mode.

Add tests. In addition to the existing test checking that the
pre-commit hook is disabled when simply picking a commit, provide a
test checking that the commit-msg hook is disabled as well.