Hi Peff,
On Sat, 9 Jun 2018, Jeff King wrote: > On Sat, Jun 09, 2018 at 08:31:58AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > 1) I really don't see the basis for this argument that they'd need to > > patch it out, they're not patching out e.g. GIT_TRACE now, which has > > all the same sort of concerns, it's just a format that's more of a > > hassle to parse than this proposed format. > > > > 2) I think you and Johannes are just seeing the "telemetry" part of > > this, but if you look past that all this *really* is is "GIT_TRACE > > facility that doesn't suck to parse". > > So that actually takes me to another question, which is: instead of > introducing a new "telemetry" feature, could we make GIT_TRACE suck less > to parse? That's a different question, and even a different concern. Please understand that this feature is needed for our own in-house use, to be able to help our users pro-actively. We really want to be able to contact a user when they struggle with the performance of any given Git command, before they have to think of reaching out for assistance. We discussed this plan at the contributor summit at GitMerge, and IIRC at least Autodesk and DropBox were interested (but of course, the changes of both Lars' and Alex' roles might make them less interested now), hence JeffHost wanted to contribute this, for the benefit of the larger Git community. > E.g., could we have a flag or environment variable to have the existing > traces output JSON? I guess right now they're inherently free-form via > trace_printf, so it would involve adding some structured interface > calls. Which is more or less what I guess JeffH's proposed feature to > look like. I think that is a much larger project than what JeffHost proposed, and would unfortunately put too much of a brake on his project. Ciao, Dscho
