Hi Alex, On Fri, 25 Oct 2019, Alexandr Miloslavskiy wrote: > 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
