From: Johannes Schindelin <Johannes.Schindelin@gmx.de> To: Alexandr Miloslavskiy <firstname.lastname@example.org> Cc: Alexandr Miloslavskiy via GitGitGadget <email@example.com>, firstname.lastname@example.org, Junio C Hamano <email@example.com> Subject: Re: [PATCH v2 1/1] vreportf: Fix interleaving issues, remove 4096 limitation Date: Fri, 25 Oct 2019 23:28:53 +0200 (CEST) [thread overview] Message-ID: <nycvar.QRO.firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> 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
next prev parent reply other threads:[~2019-10-25 21:29 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-22 14:39 [PATCH 0/1] " Alexandr Miloslavskiy via GitGitGadget 2019-10-22 14:39 ` [PATCH 1/1] " Alexandr Miloslavskiy via GitGitGadget 2019-10-22 14:45 ` [PATCH v2 0/1] " Alexandr Miloslavskiy via GitGitGadget 2019-10-22 14:45 ` [PATCH v2 1/1] " Alexandr Miloslavskiy via GitGitGadget 2019-10-25 11:37 ` Johannes Schindelin 2019-10-25 12:38 ` Alexandr Miloslavskiy 2019-10-25 14:02 ` Johannes Schindelin 2019-10-25 14:15 ` Alexandr Miloslavskiy 2019-10-25 21:28 ` Johannes Schindelin [this message] 2019-10-25 22:11 ` Jeff King 2019-10-26 8:02 ` Alexandr Miloslavskiy 2019-10-26 20:56 ` Johannes Schindelin 2019-10-26 21:36 ` Jeff King 2019-10-28 16:05 ` Johannes Schindelin 2019-10-26 21:56 ` Johannes Schindelin 2019-10-26 22:05 ` Johannes Schindelin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=nycvar.QRO.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH v2 1/1] vreportf: Fix interleaving issues, remove 4096 limitation' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).