Live data from Hacker News

GitHub CLI now collects pseudoanonymous telemetry

cli.github.com

81–90 of 368 posts

Re: GitHub CLI now collects pseudoanonymous telemetry

#81

can someone explain why github has a CLI? why wouldn't you just use git?

At my current job, I sometimes set up a Nix shell with the GitHub CLI, since that let's Claude Code associate a feature branch to a pull request. The LLM can then retrieve PR description, workflow results, review comments, etc.

Also, I believe GitHub Actions cache cannot be bulk deleted outside of the CLI. The first time I [hesitantly] used the gh CLI was to empty GitHub Actions cache. At the time it wasn't possible with the REST API or web interface.

Re: GitHub CLI now collects pseudoanonymous telemetry

#82

Do people think that GitHub isn't already collecting and aggregating all the requests sent to their servers, which is after all the entire point of the gh CLI? If you don't want your requests tracked, you're going to have to opt out of a lot more than this one setting.

[dead]

Re: GitHub CLI now collects pseudoanonymous telemetry

#83

Do people think that GitHub isn't already collecting and aggregating all the requests sent to their servers, which is after all the entire point of the gh CLI? If you don't want your requests tracked, you're going to have to opt out of a lot more than this one setting.

Data is on their server, so obviously they are already doing it, they just want to increase tracking by knowing what transit as well to Gitlab, Codeberg and such by having additional client-side metrics .

I did not get that impression from these docs or from a brief look through the gh CLI codebase. Can you point to evidence that makes you believe this is used to collect metrics about requests to other services?

Re: GitHub CLI now collects pseudoanonymous telemetry

#84

Earlier quoted context omitted.

> I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first. 1. git doesn’t have a UI, it’s a program run in a terminal environment. the terminal is the interface for the user. 2. git has a specific design that was intended to solve a specific problem in a specific way. mostly for linux kernel development. so, the UX might seem terrible…

UI means "user interface". For a CLI tool the UI is the commands and modifiers it offers on the terminal.

i lump those into user experience (UX) stuff as it’s more leaning towards “flow of user action” etc.

Re: GitHub CLI now collects pseudoanonymous telemetry

#85
post #14

Why we collect telemetry ...our team needs visibility into how features are being used in practice. We use this data to prioritize our work and evaluate whether features are meeting real user needs. I'm curious why corporate development teams always feel the need to spy on their users? Is it not sufficient to employ good engineering and design practices? Git has served us well for 20+ years without detailed analytics…

Arguably yes. git has a terrible developer experience and we've only gotten to this point where everyone embraces it through Stockholm syndrome. If someone had been looking at analytics from git, they'd have seen millions of confused people trying to find the right incantation in a forest of confusing poorly named flags. Sincerely, a Mercurial user from way back.

https://xkcd.com/1597/

Re: GitHub CLI now collects pseudoanonymous telemetry

#86

Earlier quoted context omitted.

> I'm curious why corporate development teams always feel the need to spy on their users? Is it not sufficient to employ good engineering and design practices? No, because users have different needs and thoughts from the developers. And because sometimes it's hard to get good feedback from people. Maybe everyone loves the concept of feature X, but then never uses it in practice for some reason. Or a given feature has…

> I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first. 1. git doesn’t have a UI, it’s a program run in a terminal environment. the terminal is the interface for the user. 2. git has a specific design that was intended to solve a specific problem in a specific way. mostly for linux kernel development. so, the UX might seem terrible…

"UI" is a category that contains GUI as well as other UIs like TUIs and CLIs. "UX" encompasses a lot of design work that can be distilled into the UI, or into app design, or into documentation, or somewhere else.

Re: GitHub CLI now collects pseudoanonymous telemetry

#87

Earlier quoted context omitted.

> I think yes, because git famously has a terrible UI, and any amount of telemetry would quickly tell you people fumble around a lot at first. 1. git doesn’t have a UI, it’s a program run in a terminal environment. the terminal is the interface for the user. 2. git has a specific design that was intended to solve a specific problem in a specific way. mostly for linux kernel development. so, the UX might seem terrible…

"UI" is a category that contains GUI as well as other UIs like TUIs and CLIs. "UX" encompasses a lot of design work that can be distilled into the UI, or into app design, or into documentation, or somewhere else.

[deleted]

Re: GitHub CLI now collects pseudoanonymous telemetry

#88
dev tools and especially libraries must not have telemetry unless absolutely strictly necessary (and even then!).

* Dev tools because you need to be able to trust they don't leak while you're working. Not all sites/locations/customers/projects allow leaks, and it's easier to just blacklist anything that does leak, so you know you can trust your tools, and the same habits, justfiles, etc work everywhere.

* libraries that leak deserve a special kind of hell. You add a library to your project, and now it might be leaking without warning. If a lot of libraries decide to leak, your application is now an unmanageable sieve.

If you do need to run telemetry, make it opt in or end user only. But if you as developer don't even have control then that's the worst.

Re: GitHub CLI now collects pseudoanonymous telemetry

#89
post #61
post #14

Why we collect telemetry ...our team needs visibility into how features are being used in practice. We use this data to prioritize our work and evaluate whether features are meeting real user needs. I'm curious why corporate development teams always feel the need to spy on their users? Is it not sufficient to employ good engineering and design practices? Git has served us well for 20+ years without detailed analytics…

I used to believe that it was not necessary until I started building my own startup. If you dont have analytics you are flying blind. You don't know what your users actually care about and how to optimize a successful user journey. The difference between what people tell you when asked directly and how they actually use your software is actually shocking.

> If you dont have analytics you are flying blind

More like flying based on your knowledge as a pilot and not by the whims of your passengers.

For many CLIs and developer tooling, principled decisions need to reign. Accepting the unquantifiability of usage in a principled product is often difficult for those that are not the target demographic, but for developer tools specifically (be they programming languages, CLIs, APIs, SDKs, etc), cohesion and common sense are usually enough. It also seems real hard for product teams to accept the value of the status quo with these existing, heavily used tools.

Re: GitHub CLI now collects pseudoanonymous telemetry

#90

Earlier quoted context omitted.

> I'm curious why corporate development teams always feel the need to spy on their users? Is it not sufficient to employ good engineering and design practices? No, because users have different needs and thoughts from the developers. And because sometimes it's hard to get good feedback from people. Maybe everyone loves the concept of feature X, but then never uses it in practice for some reason. Or a given feature has…

> because git famously has a terrible UI Thankfully, github has zero control over git. If they did have control they would have sank the whole operation on year one > because somebody would have looked at the stats and for instance have added "git restore" right from the very start, because "git checkout -- foo.txt" is an absolutely unintuitive command. How is git restore any better? Restoring what from when? At leas…

> How is git restore any better? Restoring what from when? At least git checkout is clear in what it does.

And this is exactly where disconnects happen, and where you need telemetry or something like it to tell you how your users actually use the system, rather than imagining how they should.

A technical user deep into the guts of Git thinks "you need to check out again this specific file".

A novice thinks "I want to restore this file to the state it had before I touched it".

Now we can argue about whether "restore" is the ideal word here, but all the same, end users tend to think it terms of "I want to undo what I did", and not in terms of git internals.

So a hypothetical git with telemetry would probably show people repeatedly trying "git restore", "git undo", "git revert", etc, trying to find an undo command.

Post reply on HN