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]
