Automatically show why a command failed

[ilan-schemoul]

Is your feature request related to a problem? Please describe.

I have pre commits. They fail sometimes. It's annoying to see the reasons of the failures. "Git command failed" I have to esc, "@", go down, enter, read the message, (fix my commit outside lazygit), esc again (because the focus is on command log), c, enter

Describe the solution you'd like

Instead of typing many keys I just want to see the error message instantly.

Additional optional idea: Maybe also a "r" to retry (so I modify the code in another window, and with "r" I stage again the files already staged (so it can incorporates the updated chunk) and I try to commit again.

Describe alternatives you've considered

"@" go down enter is also a bit too many keys as such to just see an error IMO

lazygit 0.55.1

[stefanhaller]

I suppose you have the command log set to be hidden? Me too, but it is shown by default, so normal users see the error down there without having to do anything.

I'm also not sure why you are doing the "@, go down, enter" thing. Isn't it enough to do "@, enter"? That's what I do in such a case. Or are your hook's error messages so long that seeing the last 8 lines isn't enough to tell what's wrong?

Additional optional idea: Maybe also a "r" to retry (so I modify the code in another window, and with "r" I stage again the files already staged

That would only work if you always stage entire files; it would be a very bad idea if you had only staged some files partially.

[brendanator]

My pre-commit hooks often contain well over 8 lines so I cannot see the full error message without expanding it

[TimShilov]

For me the pre-commit hook output is actually streamed in the subprocess and when things fail it makes it very easy to see. I though it was a default behavior when you have hooks and this issue confused me a bit.

I just looked into the code and it seems like subprocess is used when you have commit.gpgSign configured in .gitconfig. I feel like the logic should be changed to always use subprocess if the git repo has hooks defined. @stefanhaller WDYT?