On Tue, Apr 30, 2024 at 6:23 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > John Passaro <john.a.passaro@xxxxxxxxx> writes: > > > There's also project-specific trailers. For example, on my team, > > we use "Deploy-Strategy: ..." to tell CICD what deployment routines to run. This > > is pretty specific to us but worth calling out. Maybe could translate to a > > documentation example with something like "<Project-specific-trailer>: foo" > > The last one that uses placeholders for both trailer tag and value > may be generic enough. > done > > However, in service of helping users find workarounds, shouldn't we tell them > > --trailer may be the culprit? > > > >> Failed to read '%s'. Try again without --trailer (use -e or -F to add trailers manually). > > I dunno. > > If -m/-F that wrote the original using the open/write_or_die/close > sequence succeeded, the "amend_file" thing successfully spawned > "interpret-trailers --in-place" and got control back, yet we fail > to read that message back, it does not smell like a failure with > that "--trailer" option to me. A failure with "--trailer" that > could be worked around would have been caught in "amend_file" thing, > before the control reaches this point, no? > I considered "Failed to read '%s' after adding trailers to it". But on reflection it's really pretty difficult to imagine why this would happen at all - like it could only really happen if the call to git-interpret-trailers somehow corrupted the file. Probably best, as you say, not to speculate about the cause when telling the user what happened and potentially mislead them. Plus this wording reduces load on the l10n teams in case this patch is accepted, and allows future changes to enable this code path for other reasons with minimal change.
