Running "git blame" in a scratch buffer echoes "Press <ret> to jump
to blamed commit" even though the blaming clearly fails.  The failure
is silent because cd_bufdir exits the shell, so we don't even attempt
to run "git blame". cd_bufdir prints a "fail" command stdout but that
goes to /dev/null in this case.

I don't really understand why 891a9f5fe (Merge remote-tracking branch
'lenormf/fix-git-tools', 2019-09-22) moved cd_bufdir inside this
background subshell.  I guess it didn't matter as much back then when
we didn't have the "Press <ret> to jump" message.  Also the existing
error message printed by cd_bufdir for scratch buffers is confusing.

Fail as early as possible, showing a suitable error.  Note that "git
blame" does work in filetype=git-diff and filetype=git-log buffers,
[message trimmed]

    kak -e "hook global WinCreate /.* 'git blame'; edit README.asciidoc"

fails for no good reason because there is no client in context.
We do need a window (to add the highlighter etc) but a client is
not necessary.
---
 rc/tools/git.kak | 78 +++++++++++++++++++++++++-----------------------
 1 file changed, 40 insertions(+), 38 deletions(-)

diff --git a/rc/tools/git.kak b/rc/tools/git.kak
index c8d09346e..a0dd3899c 100644
--- a/rc/tools/git.kak
+++ b/rc/tools/git.kak
@@ -219,36 +219,34 @@ define-command -params 1.. \
[message trimmed]

For better or worse, <a-|> outputs \n, which confuses Git when the
tracked file uses \r\n line endings. Work around that.

Unfortunately this makes the "git apply" failure mode much worse: if
"diff" is not installed for some reason, the session will freeze,
without the option to ctrl-c out (which works today since we use
a shell).  I guess we can address this by switching from "diff" to
"git diff --no-index".  The only reason for using the former was that
git diff output is more complex to fix since it adds a variable number
of header lines, but we can solve that differently.
---
 rc/tools/git.kak | 31 ++++++++++++-------------------
 1 file changed, 12 insertions(+), 19 deletions(-)
[message trimmed]

A "hook global WinCreate /.* 'git blame-jump'" computes blame info
only to fail with 'unmap': no window in context.  This command cannot
hardly do anything useful without a client in context, so fail earlier.
---
 rc/tools/git.kak | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/rc/tools/git.kak b/rc/tools/git.kak
index 0e1a65083..609c0a566 100644
--- a/rc/tools/git.kak
+++ b/rc/tools/git.kak
@@ -537,6 +537,10 @@ define-command -params 1.. \
     }
 
[message trimmed]

git.kak has two NormalIdle hooks that run "execute-keys vv" and print
a status line message.
The NormalIdle hook is only necessary for "execute-keys vv".
(as a workaround for https://github.com/mawww/kakoune/issues/5082).

Since we run "git blame" in the background, it will not trigger a
NormalIdle hook when finished.  This means that the "failed to run
git blame" message will only be shown after the next key press.

Remove the unneeded hook to show this error message immediately.
To avoid a race condition, make sure that the mapping commands are
executed before any error.

Also reduce the scope of the other hooks to prevent similar copy-paste
[message trimmed]

Mostly independent patches.

 rc/tools/git.kak                         | 147 +++++++++++++++----------------
 test/tools/git/blame-jump-message/script |   6 +-
 2 files changed, 75 insertions(+), 78 deletions(-)

This fails because the new logic wrongly assumes the presence of a client:

    hook global WinCreate /.* 'git show-diff'

The "diff" process hangs because we never write to ${kak_response_fifo}.
After a "pkill diff", the *debug* buffer shows

    error while waiting for shell: 1:1: 'evaluate-commands': 3:13: 'execute-keys': no such client: '-draft'
    shell stderr: <<<

The client argument is completely unnecessary since we always want
to use the calling context's buffer anyway. Remove it.

Note that we can probably further simplify this by using "write"
[message trimmed]

---
 rc/tools/git.kak | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/rc/tools/git.kak b/rc/tools/git.kak
index 828d3c152..4277a06d9 100644
--- a/rc/tools/git.kak
+++ b/rc/tools/git.kak
@@ -200,8 +200,11 @@ define-command -params 1.. \
         }"
         git show "$rev:${buffile_relative}" |
             diff - ${kak_response_fifo} "$@" |
-            sed -e "1c--- a/$buffile_relative" \
-                -e "2c+++ b/$buffile_relative"
[message trimmed]

Staging/unstaging/reverting (parts of) the current buffer's file can
be a common use case.

Today "git apply" can do that based on a selection within a diff.
When the selection is on uncommitted content, we can probably assume
that the intent is to use the part of the selection that overlaps
with the +-side of "git diff" (or "git diff --cached" for
"git apply --cached").

Make "git apply" treat selections as content if the buffile is
tracked by Git. This differentiator is not perfect but I don't know
why anyone would want to use the existing "git apply" semantics on
a tracked file. Maybe we should pick a different name.
[message trimmed]

We pipe the output of the patch program to stderr (to have it show
up in *debug*) and print to stdout the remaining diff (the part of
the diff that was not passed to patch).

The next patch wants to use this script in a different way, so move
these decisions up.
---
 rc/tools/patch-range.pl | 42 ++++++++++++++++++++++++++---------------
 rc/tools/patch.kak      |  2 +-
 2 files changed, 28 insertions(+), 16 deletions(-)

diff --git a/rc/tools/patch-range.pl b/rc/tools/patch-range.pl
index 978f45c35..2d54ab26f 100755
--- a/rc/tools/patch-range.pl
[message trimmed]