FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
72% Positive
Analyzed from 2082 words in the discussion.
Trending Topics
#telemetry#github#cli#git#config#features#export#don#used#data

Discussion (175 Comments)Read Original on HackerNews
[1] https://docs.brew.sh/Analytics
I'm not sure if you're implying it's obvious but it's not obvious to me that it would be unhelpful.
It's not that it's insufficient, new developers, product people and designers literally don't know how to make tasteful and useful decisions without first "asking users" by experimenting on them.
Used to be you built up an intuition for your user base, but considering everyone is changing jobs every year, I guess people don't have time for that anymore, so literally every decision is "data driven" and no user is super happy or not anymore, everyone is just "OK, that's fine".
There are all sorts of best practices for getting info without vacuuming up everyone’s data in opaque ways.
The problem I have with a lot of these analytics is that while there are harmless ways to use it, there is this understanding that they could be tying your unique identifier to behavioral patterns which could be used to reconstruct your identity with machine learning. It's even worse if they include timestamps.
Why not just expose exactly what telemetry is being sent when it's sent? Like add an option that makes telemetry verbose, but doesn't send it unless you enable it. That way you can evaluate it before you decide to turn it on. Whenever you do the Steam Hardware survey it'll show you what gets sent. This is the right way to do it.
The opt-out situation for gh CLI telemetry is actually trickier than it sounds. gh runs in CI/CD pipelines and server environments where you may not want any outbound connections to github.com at all, not because of privacy but because of networking constraints. In those environments, the telemetry being on by default means your CI fails or your Bastion host can't reach GitHub at all.
Compare this to git itself, which is entirely local until you explicitly push. The trust model is different: git will never phone home unless you configure it to. gh, being a wrapper around the GitHub API, has to make those calls to function - but that's separate from whether it should also be collecting and uploading your command patterns.
If you don't want your requests tracked, you're going to have to opt out of a lot more than this one setting.
> Removes the env var that gates telemetry, so it will be on by default.
Those two words have almost exactly opposite meanings, and as stated, they are literally saying they are collecting identifiable data.
Embrace, extend, extinguish.
The first two have been done.
I give it five years before the GH CLI is the only way to interact with GitHub repos.
Then the third will also be done, and the cycle is complete.
I'll take that bet. How much are you willing to put on it?
A quick summary of my Claude-assisted research at the Gist below. Top of mind is some kind of trusted intermediary service with a vested interest in striking a definable middle ground that is good enough for both sides (users and product-builders)
Gist: WIP 31 minutes in still cookin'
P.S. You look like villain from Temu.
And less social media shit, maybe adding better LFS alternative similar to huggingface and stuff.
Git isn't the popular choice in game dev because of this assets in tree hosting nonsense, why haven't we fixed it yet.
Similarly many edge cases, also finally they built stacked prs but man does it feel a under baked, and what it's like 2+ years late.
Please just improve Github, make me feel like I will be missing out if I am not on Github because of the features not because I have to be because of work.
* 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.
Today I use a Golang CLI made with ~200K LOC to do essentially the same thing. Yay, efficiency?
Regulators should wake up and fine them hard, so hard to become existential. Make an example for others not to follow.
I know lots of idealists -- I went to a public policy school. And in some areas, I am one myself. We need them; they can push for their causes.
But if you ever find yourself working as a regulator, you'll find the world is complicated and messy. Regulators that overreach often make things worse for their very causes they support.
If you haven't yet, go find some regulators that have to take companies all the way to court and win. I have know some in certain fields. Learn from them. Some would probably really enjoy getting to talk to a disinterested third-party to learn the domain. There are even ways to get involved as a sort of citizen journalist if you want.
But these sort of blanket calls for "make an example of GitHub" are probably a waste of time. I think a broader view is needed here. Think about the causal chain of problems and find a link where you have leverage. Then focus your effort on that link.
I live in the DC area, where ignorance of how the government works leads to people walking away and not taking you seriously. When tech people put comparable effort into understanding the machinery of government that they do into technology, that is awesome. There are some amazing examples of this if you look around.
There are no excuses. Tech people readily accept that they have to work around the warts of their infrastructure. (We are often lucky because we get to rebuild so much software ourselves.) But we forget what it's like to work with systems that have to resist change because they are coordination points between multiple stakeholders. The conflict is by design!
Anyhow, we have no excuse to blame the warts in our governmental system. You either fix them or work around them or both.
The world is a big broken machine. Almost no individual person is to blame. You just have to understand where to turn the wrench.
the old git command in your terminal
I think I'll keep using that
It might seems legit from them, but I'm quite sure that just listening to your user is enough. It is not like they lack an user base ready to interact with them or that they lack of bugs or features to work on.
In most cases, the telemetry is more a vanity metric that is rarely used. "Congratz to this team that did the flag that is the most used in the cli". But even for product decision, it is hard to extract conclusions from current usage because what you can and will do today is already dependent on the way the cli is done. A feature might not be used a lot because it is not convenient to do, or not available in a good way compared to an alternative, but usage report will not tell if it was useful or not. In the same way, when I buy a product, often there are a lot of features that I will never use, but that I'm happy to have. And I might not have bought the product, or bought another one if it was not available. But the worse would have the manufacturer remove or disable the feature because it is not used...
Corporations can and will do every scummy thing permitted to them by law, so here we are. Until the US grows a backbone on issues of privacy, we shouldn't be surprised, I suppose. But the US won't be growing such a backbone anytime in the near future.
export GH_TELEMETRY=false
export DO_NOT_TRACK=true
gh config set telemetry disabled
gh version 2.90.0 (2026-04-16) https://github.com/cli/cli/releases/tag/v2.90.0
$ gh config set telemetry disabled
! warning: 'telemetry' is not a known configuration key
Also note that even though you get a warning about an unknown config key, the value is actually set so you're future-proof. Check `grep telemetry ~/.config/gh/config.yml`
What's strange is if you check your `~/.config/gh/config.yml` it will put `telemetry: disabled` in there. But it will put anything in that `config.yml` lol.
> gh config set this-is-some-random-bullshit aww-shucks > ! warning: 'this-is-some-random-bullshit' is not a known configuration key
But in my config.yml is
this-is-some-random-bullshit: aww-shucks