[Feature Request / Usability Issue] The Git Error window is very small, makes it likely to miss important messages from hooks

[hybridherbst]

Hi, we're using some pre-receive hooks on the server and use these to communicate failures to users (e.g. files are larger than X, similar to what GitHub does). However, devs tend to miss these notices as the "warning/error window" always opens up in the same small state and doesn't show the relevant info.

Would it be possible to improve this window, e.g. by

• enlarging it
• moving the important messages to the top if possible
• showing in the error popup window title already what went wrong (e.g. "pre-receive hook failed")?

That would make user error less likely and reduce confusion a lot.

Example of the problem:

Thanks!

[DanPristupov]

enlarging it

Making it wider doesn't make sense because lines don't usually wider that 80 symbols. Height can be increased, but it won't make much difference.

moving the important messages to the top if possible

How can we recognize them?

showing in the error popup window title already what went wrong (e.g. "pre-receive hook failed")?

How can we find out what's wrong? Fork only has the data you see on the screen.

[hybridherbst]

My understanding is that the order of returned values here is always:

• logs regarding the upload ("counting/compressing objects", "write")
• echo output from the remote, always starts with "remote: "
• reason for the error (! [remote rejected]), and the reason, e.g. "pre-receive hook declined" here

I'm not super familiar with the error outputs from git but it seems to always be the same pattern and thus should be parseable and put into a better form (e.g. upload process, errors, which hook produced the errors).

What I'd love to see here is that instead of "unexpected error" this window reads "[remote rejected] pre-receive hook declined" or so, basically the main reason outlined in the log, and that there's a differentiation between "just the regular uploading process messages" and the (important!) "remote: " output from the server.

A quick fix would indeed be that the window expands in height, not sure why that wouldn't make a difference. The main issue here is that the tiny window hides the important messages and prioritizes the less interesting start of the log :)

I think the data on screen is enough to figure out what went wrong and give a better "first glimpse" at that. I can only tell from experience here that since people can't distinguish between "unexpected git error for unknown reasons" and "expected git error since the pre-receive hook failed with a specific message" the expected errors get discarded unseen and people are confused why things fail.

I'd argue that this is a "bug" in the sense that the error isn't unexpected, it's expected since the files are too large and someone on the server side bothered to implement a pre-receive hook with proper messaging for that.

[Zguy]

Since the actual error is usually at the bottom of the log, I think a good first step for this would be for it to be scrolled all the way to the bottom when it opens.

[hybridherbst]

@DanPristupov found another case where this matters, when Fetch et al don't work because of e.g. someone having moved around tags on the backend (a common operation in larger repos):

Expanded window scrolled to the bottom immediately shows the issue (albeit this is one with no clear resolution steps – I don't even really know what it means, I just know I can delete the local tag as workaround and fetch again):

In this case, the window says "Unexpected error", but the message further down is "[rejected] SomeTag (would clobber existing tags)". Since the window is so small that is easily missed and people instead think they have e.g. no network connection, the remote is down, ... or other issues.

(It's also the same pattern of the actual rejection message starting with ! [error] error-line-with-infos)

[Otiel]

I too find the git error window too small (height and width). Git error logs are often quite verbose in my experience, and the 7 lines-height that are currently displayed are not enough too easily find the error in the wall of text.

The first thing I do every time there's a git error is WinUp in order to maximize the window and see clearly what's going on. That's okay for me, but I think it speaks for itself to show that there's room for improvement.

[hybridherbst]

Another example:

Scrolled down

What would already be an improvement: slightly larger (wider and higher) and scrolled down