0

I have a pre-commit hook in git that returns nonzero on some "fatal" QA checks.

When using git commit on the command line, git bails out. However, when trying the very same commit in Magit, Magit continues on presenting the commit message buffer.

I would like Magit to bail like git does.

I don't have anything related to Magit in my init file beyond (use-package magit).

Magit version: Magit 20201110.1643, Git 2.26.2, Emacs 27.1, gnu/linux

Magit process buffer ($):

  1 git … commit --signoff
pre-commit running in /home/titan/repos/gentoo
Running repoman for: app-office/gnucash
      digest.unused                 3
       /home/titan/repos/gentoo/app-office/gnucash::gnucash-3.8b.tar.bz2
       /home/titan/repos/gentoo/app-office/gnucash::gnucash-4.0.tar.bz2
       /home/titan/repos/gentoo/app-office/gnucash::gnucash-4.1.tar.bz2
    Non-Fatal QA errors found
pre-commit done in /home/titan/repos/gentoo
hint: Waiting for your editor to close the file...
Waiting for Emacs...

I've programmed the script to consider unused digest items to be an error. So, the script returns 1.

Edit: Well, I've done nothing...and now it works as expected. Something must have gotten stuck.

Improve this question
2
  • @phils, I've updated the question to include that information.
    – titanofold
    Nov 21, 2020 at 19:33
  • 1
    If your pre-commit script is exiting with a non-zero status then normally Magit would not get to the point of asking you to edit a commit message, and I think that's a consequence of git not trying to start the user's editor at all in that situation. To me this looks like either git trying to get a commit message from you despite the pre-commit failure, or else the pre-commit script not actually returning non-zero. I've no idea whether the --signoff option is a factor, but you could try it without that.
    – phils
    Nov 21, 2020 at 22:08

1 Answer 1

Reset to default
1

Magit simply runs git commit ..., git then invokes $EDITOR, which Magit has arranged to be emacsclient ..., so that ends up calling back into the same Emacs instance.

git commit may decide that the commit should not be created after all, e.g. because there are no changes that could be committed or because the pre-commit hook exits with a non-zero exit status. In that case it needs no commit message, so it simply does not call the $EDITOR. This does not appear to be what is happening here; git commit does not abort.

Looking at the output you provided, we can see that only Non-Fatal QA errors [were] found. Therefore the pre-commit hook exits with a zero status, communicating to git commit that there is no reason to abort, and that uses $EDITOR to have you write the message.

Compare the hook output to the output that you get on the command line. Does it here say that the QA errors are fatal? If so, then this difference is probably due to configuration and you then have to figure out why that configuration appears to be ignored when git commit is invoked from inside Magit instead of from inside a shell. My guess would be on environment variables that are set in your shell's configuration files, which don't apply to Emacs because you don't start Emacs by typing emacs into a terminal.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.