git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC PATCH v1] telemetry design overview (part 1)

From
Duy Nguyen <pclouds@gmail.com>
Date
Jun 9, 2018, 07:31 UTC
Message-ID
<CACsJy8DrtAdwH0dOjptJ0JDQ_gOeiTVbRknui4gM5P85Y5JZow@mail.gmail.com>
In-Reply-To
<87bmck4gip.fsf@evledraar.gmail.com>
On Sat, Jun 9, 2018 at 8:32 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
Show 6 quoted lines
> Let's say you're in a corporate environment with Linux, OSX and Windows
> boxes, but all of whom have some shared mounts provisioned & ability to
> ship an /etc/gitconfig (wherever that lives on Windows).
>
> It's much easier to just do that than figure out how to build a custom
> Git on all three platforms.

Let's say I don't care about making it easier on corporate environment. You have resources to do that.

Show 25 quoted lines
> > Not making it a compile-time option could force [1] linux distro
> > to carry this function to everybody even if they don't use it (and
> > it's kinda dangerous to misuse if you don't anonymize the data
> > properly). I also prefer this a compile time option.
>
> Setting GIT_TRACE to a filename that you published is also similarly
> dangerous, so would setting up a trivial 4-line shell alias to wrap
> "git" and log what it's doing.
>
> > [1] Of course many distros can choose to patch it out. But it's the
> > same argument as bringing this option in in the first place: you guys
> > already have that code in private and now want to put it in stock git
> > to reduce maintenance cost, why add extra cost on linux distro
> > maintenance?
>
> Because:
>
> 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".

If it's simply an improvement over GIT_TRACE, then I have no problem with that. That is:

- there is no new, permanent way to turn this one like config keys
- there's no plugin support or whatever for keeping output. Keep it to
either a file or a file descriptor like we do with GIT_TRACE.
Show 11 quoted lines
>    There's a lot of use-cases for that which have nothing to do with
>    what this facility is originally written for, for example, a novice
>    git user could turn it on and have it log in ~ somewhere, and then
>    run some contrib script which analyzes his git usage and spews out
>    suggestions ("you use this command/option, but not this related
>    useful command/option").
>
>    Users asking for help on the #git IRC channel or on this mailing list
>    could turn this on if they have a problem, and paste it into some
>    tool they could show to others to see exactly what they're doing /
>    where it went wrong.

And they can use GIT_TRACE now. If GIT_TRACE does not give enough info (e.g. too few trace points), add them. This new proposal is more about automation. With GIT_TRACE, which is more human friendly, I could skim over the output and remove sensitive info before I send it out for help. Machine-friendly format (even json) tends to be a lot more complex and harder to read/filter this way.

-- 
Duy
Previous: Jeff KingNext: Jeff King
Message 14 of 27 in “telemetry design overview (part 1)”
  1. telemetry design overview (part 1)git@jeffhostetler.com, Jun 7, 2018
  2. telemetry: design documenationgit@jeffhostetler.com, Jun 7, 2018
  3. Ævar Arnfjörð BjarmasonJun 8, 2018
  4. Johannes SixtJun 7, 2018
  5. Jeff KingJun 8, 2018
  6. Thomas BraunJun 8, 2018
  7. Johannes SixtJun 8, 2018
  8. Ævar Arnfjörð BjarmasonJun 8, 2018
  9. Duy NguyenJun 9, 2018
  10. Ævar Arnfjörð BjarmasonJun 9, 2018
  11. Jeff KingJun 9, 2018
  12. Johannes SchindelinJun 9, 2018
  13. Jeff KingJun 11, 2018
  14. Duy NguyenJun 9, 2018
  15. Jeff KingJun 9, 2018
  16. Johannes SixtJun 9, 2018
  17. Jeff KingJun 9, 2018
  18. Junio C HamanoJun 12, 2018
  19. Johannes SixtJun 9, 2018
  20. Johannes SchindelinJun 9, 2018
  21. Johannes SixtJun 9, 2018
  22. Jeff KingJun 11, 2018
  23. brian m. carlsonJun 10, 2018
  24. Jeff KingJun 11, 2018
  25. Jeff KingJun 11, 2018
  26. Ævar Arnfjörð BjarmasonJun 8, 2018
  27. Duy NguyenJun 8, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.