On Fri, Oct 22 2021, Johannes Schindelin wrote: > Hi Bagas, > > On Fri, 22 Oct 2021, Bagas Sanjaya wrote: > >> On 21/10/21 18.56, Johannes Schindelin wrote: >> > 5. The challenge is not necessarily the technical challenges, but the UX >> > for >> > server tools that live “above” the git executable. >> > >> > 1. What kind of output is needed? Machine-readable error messages? >> > >> > 2. What Git objects must be created: a tree? A commit? >> > >> > 3. How to handle, report, and store conflicts? Index is not typically >> > available on the server. >> >> 1) I prefer human-readable (i.e. l10n-able) output, because the output >> messages for server-side merge/rebase are user-facing. > > For server-side usage, a human-readable output _by Git_ would not make > sense. It would be the responsibility of the server-side caller (which is > usually a web application) to present the result, potentially translated, > definitely prettified. > > So while I agree with you that the result should be made pretty on the > server side, I disagree that this is Git's job. Instead, Git should > produce something eminently machine-parseable in this context. Our server-side already produces human-readable output via die() messages or ERR packets. To the extent that we need human-readable output in say protocol v2 I think it makes more sense to start supporting passing over the user's locale to look the appropriate thing up in our *.mo files. The alternative is maintaining an exhaustive catalog of unique error ID's or whatever. Most things should of course have meaningful error codes etc., I'm only referring to the output that has some human readable "we've failed, and here's a text explanation for why" component, see the various places in protocol v0..2 where we emit that, e.g. telling a user what went wrong with the "filter" arguments they provided etc.
