Hi Alex,

On Fri, 25 Oct 2019, Alexandr Miloslavskiy wrote:

On 25.10.2019 16:02, Johannes Schindelin wrote:

quoted

My example is even worse (read: more convincing), though:

fatal: git uploadfata-lp: raemcokte :error:  upload-pnot our arcef k6: n4ot
our ea4cr1e3f 36d45ea94fca1398e86a771eda009872d63adb28598f6a9
8e86a771eda009872d6ab2886

So maybe you want to use that?

OK.

quoted

Again, I don't think that it is wise to try to make this work for
arbitrary sizes of error messages.

quoted

My point is: I don't want to "fix" truncation. I actually think of it
as a feature

It would be helpful to hear opinions from someone else, before the patch is
reworked significantly.

If you must wait, well, then you must.

The commits you found seem to suggest already that there is support for
clipping the message, but hey, what do I know, maybe the mood changed
over the years.

Since I have to re-run CI/PR builds regularly that failed due to t5516,
I will be very tempted _not_ to wait, though.

quoted

I know _which_ two processes battle for `stderr`.

I think I said the same in code comment, bullet 3, near t5516?

Probably.

A code comment about a test case that is not in the very vicinity of
said comment is _prone_ to get stale.

In other words: this information does not belong into a code comment. It
belongs into the commit message.

If you needed any indication that this is true: I would not have missed
this important piece if it had been in the commit message (instead of
the code with whose added complexity I disagree).

Ciao,
Dscho