6

Whenever Git fails (e.g. if you try to rebase when your working tree has changes), Magit writes the following message:

Git failed ... [See buffer *magit-process: ... for details]

which is then immediately obscured with other stuff like

Reverting (up to) 670 file-visiting buffer(s)...

In other words it is extremely non-obvious when and why something fails, especially if you don't watch it closely, e.g. commit and switch to a different desktop, for example.

Is there any way to make Magit bark hard when Git underneath it fails, e.g. pop some buffer?

4

Edit: The last error messages is now also shown in the status buffer. You'll know it when you see it. But it is only shown in the status buffer - if that buffer is not visible, then the message can only be seen in the echo area. So everything said below about how to make sure you get to see the message there, still applies.

Also note that the message is only shown in the status buffer until that is refreshed.


When a git process exits with a non-zero exit status, then magit tries to find an error message in git's output. So usually you should see e.g.:

Could not read from remote repository. ... [See buffer *magit-process: use-package for details]

Git failed is only used if git did not output anything resembling an error message.


But you are right, without any user configuration, these error messages are usually drowned in a see of messages about buffers being reverted. The last of these messages reads like this:

Reverting 55 file-visiting buffer(s)...done
This can be undone using `C-/' in the affected buffers
Customize behavior using `M-x customize-option RET magit-revert-buffers RET'

My hope was that this is verbose enough to annoy users sufficiently to actually bother customizing the mentioned variable. When you do that, then you will get to read its doc-string, which explains that you should set the value to silent and (to some extend) why that isn't the default:

‘usage’   Like ‘t’ but include usage information in the summary.
          This is the default so that users come here and pick
          what is right for them.

‘silent’  Revert the buffers synchronously and be quiet about it.
          This is the recommended setting, because for the other
          values the revert messages might prevent you from
          seeing other, more important, messages in the echo
          area.

So change the value to silent and you should get to see the error messages in most cases. There might be other messages which shadow the git error messages in some cases, but that's expected to be rare.


The reason we are forcing users to read the doc-string and to change the value from the actual default to the intended default, is that there is a tiny risk of data loss, when buffers are reverted without the user being aware of it. So we do revert by default (because that's very useful), but we do it very verbosely and tell the user how to undo the reverts. (And also suggest that s/he configures the variable, which is the part you missed.)

Q: When could the automatic reverts lead to data-loss?

If the buffer has unsaved changes, then Emacs won't attempt to revert; so no risk here. If the buffer is saved and that caused the file in the working tree to contain uncommitted changes, then git refuses to perform any action which would lose these changes; so no risk here. There only is a risk, if you knowingly use buffers as a staging area (without knowing about the automatic reverts by magit). For example: Make changes, save, and commit. Notice that you should for some reason not have committed. Do a hard reset to HEAD~, expecting the buffer not to be reverted. What you should do instead (as in "take full advantage of Git and the nice wrapping provided by Magit") is a soft reset, but ...

Q: So if the risk of data loss is tiny, why are you doing all that?

... not every user might realize that, so we play it safe.

Q: But...?!

See https://github.com/magit/magit/issues/1809.

  • Thanks for adding the status buffer notification, tarsius. I was very happy the first time I saw that appear :) – phils Apr 15 '16 at 7:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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