Re: [PATCH v2 1/1] vreportf: Fix interleaving issues, remove 4096 limitation

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Oct 25, 2019, 21:28 UTC
Message-ID: <nycvar.QRO.7.76.6.1910252323490.46@tvgsbejvaqbjf.bet>
In-Reply-To: <4bd58e13-4e6e-5122-6127-4399d34fde43@syntevo.com>

Hi Alex,

On Fri, 25 Oct 2019, Alexandr Miloslavskiy wrote:

Show 19 quoted lines

> On 25.10.2019 16:02, Johannes Schindelin wrote:
> > 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.
>
> > Again, I don't think that it is wise to try to make this work for
> > arbitrary sizes of error messages.
>
> > 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.

> > 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