bug/defaults: COMMIT_EDITMSG not reused after a failed commit

Hi,

* What did you do before the bug happened? (Steps to reproduce your issue)

I have commit signing configured, using 1Password as an ssh-signer.

    [gpg]
        format = ssh

    [gpg "ssh"]
        program = "/Applications/1Password.app/Contents/MacOS/op-ssh-sign"

Sometimes signing a commit fails, because 1PW has updated and needs restarted
or something, I haven't been motivated to figure it out. But that's not the
issue, there could be many reasons a commit fails.

    $ git commit
    <editor opens, write beautiful commit message prose>

    error: 1Password: Could not connect to socket. Is the agent running?

    fatal: failed to write commit object

If I restart 1Password, and do `git commit` again (signing works), my previous
commit message is wiped and I need to start afresh.

* What did you expect to happen? (Expected behavior)

If a commit fails for whatever reason, I expect to be able to re-commit and it
would reuse my carefully crafted message.

* What happened instead? (Actual behavior)

It got dropped on the floor and I needed to rewrite the whole thing.

* What's different between what you expected and what actually happened?
* Anything else you want to add:

The git-commit docs state:

    $GIT_DIR/COMMIT_EDITMSG
        This file contains the commit message of a commit in progress. If
        git commit exits due to an error before creating a commit, any
        commit message that has been provided by the user (e.g., in an
        editor session) will be available in this file, but will be
        overwritten by the next invocation of git commit.

So, yes, technically I can copy it or use `git commit -F .git/COMMIT_EDITMSG`
but this seems like a distinctly unhelpful default behaviour to me. Thoughts:

- descriptive commit messages are good
- most commits succeed
- if a commit fails, the user _wanted_ to commit, so why would they _want_ to
  drop the message they've previously written?
- even if a commit fails and the user does something completely different and
  now wants a different message, deleting a chunk of text is vastly easier than
  rewriting something.

While successful commits also leave the previous commit message in
.git/COMMIT_EDITMSG, this is _not_ documented behaviour (it only talks about a
"commit in progress"); so feels like we could change it:

1. delete COMMIT_EDITMSG on success
2. reopen COMMIT_EDITMSG on commit if it exists. Maybe logging something like
   "Restoring previous in-progress commit message..." might explain what's
   happening.
3. if COMMIT_EDITMSG doesn't exist, re-populate from the template before opening
   the editor. We could also do this for "parsed-as-empty" commit messages.

I just don't see any particular upside to the current default behaviour?

Rob :)


[System Info]
git version:
git version 2.39.3 (Apple Git-146)
cpu: arm64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
uname: Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May  1 20:12:58
PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
compiler info: clang: 15.0.0 (clang-1500.3.9.4)
libc info: no libc information available
$SHELL (typically, interactive shell): /opt/homebrew/bin/zsh

[Enabled Hooks]