GitHub CLI now collects pseudoanonymous telemetry

[-]

gplusplus314@reddit

This is so stupid. Almost everything the GitHub CLI does is API interactions with GitHub. All the telemetry you’d ever want already exists servers-side.

This reeks of product management because I find it hard to believe that an engineer could be this stupid.

[-]

Some things are only client-side like users writing the wrong command because that's more intuitive. With this tracking, it would be possible to add aliases so that people can use it more comfortably.

[-]

sue_dee@reddit

Heh, I know that this is git rather than github, but one of these days I may just make git ass an alias for git add with how often I fat finger that.

[-]

gplusplus314@reddit

Or, maybe, your biggest mistake is using qwerty to begin with. 😎

Haha

[-]

gplusplus314@reddit

On a purely technical level, you’re right.

On a practical level, I think the usefulness of such information is grossly overstated and I’m just skeptical of GitHub’s/Microsoft’s intentions.

Remember, folks, this is the same Microsoft that bought GitHub and said they weren’t going to change it. Then they changed it and continued to lay off GitHub employees and close job openings. The same Microsoft that continuously fires its own employees and releases things like Windows Recall and critical Windows bugs that brick systems while simultaneously bragging about more AI coding. The same Microsoft that thought it was necessary to mass-email an apology letter for making their products terrible. The same Microsoft that banned people from various social media channels for calling them MicroSlop.

My rant isn’t toward you or your perfectly sound technical argument, it’s against Microsoft.

[-]

art_of_snark@reddit

Claude Code invokes the gh cli by default, they’re trying to shift users (money) to Copilot.

[-]

ammie12@reddit

even anonymous telemetry still feels unnecessary for a cli tool

[-]

phylter99@reddit

They want to know what features are being used, so they can focus more on improving those features or remove things that are not being used. It sounds reasonable. I don't have any clue if they're doing more than that with it, and I'm not sure how much I trust them. They don't need my information.

[-]

algaefied_creek@reddit

Ye. And likely want to know which commands by their own Copilot CLI are being used, are they being used in a token-effective manner, etc.

[-]

wandering_melissa@reddit

yeah I thought the same but not just copilot, also claude code, opencode etc. any agentic AI

[-]

phylter99@reddit

They have a naming problem. GitHub CLI isn’t the same as Copilot CLI. They always make things way more confusing than it needs to be.

I mention it because I got caught up in it the other day.

[-]

algaefied_creek@reddit

I’m explaining poorly, because I’m speaking about a topic beyond my expertise so thanks for bearing with me.

Let me see if I can describe what I mean:

When Copilot CLI is using the GitHub MCP, I would hanker a guess that MCP is using gh. Likewise for using its own built-in bash commands.

Copilot seems to regularly fail at interacting with gh for arbitrary yet bizarre reasons such as: uploading all .gitignored artifacts after moving them to a different folder when running make clean: resulting in gigabytes of LFS objects uploaded, maxxing out the LFS storage, leaving one unable to download anything other than pointers until resolving.

So perhaps, Microsoft/GitSlop are trying to train it real workflows and workarounds by users.

[-]

Farados55@reddit

They’re gonna check how many times I type gh pr open instead of create

[-]

edparadox@reddit

Is there a reason to use GitHub CLI rather than plain Git CLI?

[-]

Maskdask@reddit

You can do GitHub specific things like list PRs, check out PRs from just a PR number, create PRs, create forks, etc.

[-]

ottovonbizmarkie@reddit

Also using it push things like docker images to ghcr.io and such.

[-]

abotelho-cbn@reddit

Oh, so vendor locking yourself.

[-]

NeuroXc@reddit

This may be the stupidest comment I've read today. You use the git CLI and gh CLI together. The gh CLI is designed for interacting with Github specifically. Pull requests are not a feature of git, they are a feature of Github, so why would the git CLI give you a way to interact with them?

But you're getting upvoted because "github bad herpderp" I hate this fucking site

[-]

abotelho-cbn@reddit

interacting with Github specifically

push things like docker images

Derp.

[-]

JimmyRecard@reddit

Your corporate rage is well noted.

[-]

NeuroXc@reddit

Anyone who prefers facts and logic is a corporate shill... Got it. I don't even host my repos on Github but at least I know how it works.

[-]

nullptr777@reddit

I don't think you know what vendor-locking means...

[-]

abotelho-cbn@reddit

I absolutely do.

Why would someone base their tooling around a tool that only works with one vendor when they could use the existing generic tooling?

[-]

gplusplus314@reddit

Umm… okay, show us how to make a pull request using a totally vendor agnostic toolchain. I already know the answer: you can’t.

[-]

DeliciousIncident@reddit

Wrong comment. The reply was made on pushing docker images, not on creating pull requests.

[-]

gplusplus314@reddit

The comment had the word “also” in it, describing that the tool is capable of more than one thing and it offers some conveniences.

[-]

the9spades@reddit

Just call the endpoint? The tool would just need a tiny adapter for whatever vendor is used, there's no vendor specific data or metadata required.

[-]

gplusplus314@reddit

Hold on, let’s see if you can put the dots together…

Call the endpoint. Which endpoint? The vendor-specific GitHub endpoint?

Yea. That one.

[-]

the9spades@reddit

Hence the adapter, that's how most of the ssoftware works.

For fully vendor agnostic just send a patch with git send-email, there's no need to use GitHub at all.

[-]

gplusplus314@reddit

That’s an incredibly impractical strategy. Nobody is putting their source code on GitHub and simultaneously worrying about vendor lock-in of a CLI tool that is an alternative to GitHub’s UI. Even if you did have some kind of adapter-based vendor agnostic CLI, it’s an exercise in futility because all roads would still lead back to GitHub.

It’s not a real problem - you’re making mountains out of mole hills.

[-]

nullptr777@reddit

Because if you want to push a one-off test image or something, it's easier to use the tool you're already using rather than manage authentication for a second one?

Worst case scenario, even if you build your entire workflow around it, you have to change maybe a couple of lines of code. Even if you have to do that across 100 repos, assuming you employed DRY practices, it isn't a big deal. That isn't vendor lock-in, that's a mild inconvenience.

Vendor lock-in is when you do something much stupider, like go all in on Azure DevOps with Bicep. You're never getting out of that ecosystem at that point.

[-]

Vuiz@reddit

The "locking" -part here is very loose though. You can swap out Github very easily.

Atlassian is a good example of this, speaking from experience. Get yourself a suite of Confluence, Jira and Bitbucket for 5-10k users; Then we can talk about a proper vendor lock-in.

[-]

Unicorn_Colombo@reddit

The only advantage of Atlassian offers is that everyone will hate the products so they will like it when you move away from them.

[-]

Hahehyhu@reddit

how is it vendor locking if the cli is designed to interact with the platform itself in the first place????? would you use gitlab cli to interact with github instance?

[-]

abbidabbi@reddit

check out PRs from just a PR number

git fetch --force $REMOTE refs/pull/$PR/head:local-branch-name

create PRs

Why would I use a CLI tool for that? If I submit a PR, even on my own projects, I want to write a proper PR description with properly formatted markdown that I want to preview first. Using the commit message as an automated PR description is not always useful. Projects can also have PR description templates. I've seen numerous people ignoring our templates in the past (after they've submitted slop and also ignored our AI contribution guidelines). Now I know why...

[-]

StickyDirtyKeyboard@reddit

You get a list of templates from the repo that you can select from when you use it to create a PR. So I don't believe there is any difference in functionality when it comes to templates.

I much prefer creating PRs with it because it lets me stay in the terminal and use an editor I'm comfortable with (nvim). If the markdown doesn't come out the way I expect, I can always edit it. I usually check immediately after submitting with gh pr view {pr_num} --web

[-]

thedeathbeam@reddit

Idk if you worked through corporate proxy before but CLI is 5 times faster than loading github website that i cant access without proxy. You can fill whatever you want through the CLI as well. Or at least that was my biggest reason to heavily switching to CLI use over going to the actual website.

[-]

gplusplus314@reddit

You can do a whole lot more with the GitHub CLI than just git check out PRs. For PRs specifically, you can do everything you can do in the PR web UI, but over command line. That includes interacting with comments, monitoring checks and actions, all sorts of stuff.

It’s generally useful for automations.

The GitHub SDK is powerful, too. The CLI is basically a wrapper around their SDK.

[-]

Tblue@reddit

In order to send pseudoanonymous telemetry to GitHub <3

[-]

MairusuPawa@reddit

Can I send it fart noises instead?

[-]

GovernmentSimple7015@reddit

Dealing with GitHub release, actions, etc.

[-]

Brillegeit@reddit

Issues as well.

[-]

ChocolateDonut36@reddit

pseudo anonymous is a wild way to say not anonymous

[-]

ThePierrezou@reddit

thanks microslop i guess

[-]

Crilde@reddit

Enjoy collecting all that telemetry from my pipelines, hope you learn a lot about opening PRs when auto-patching succeeds/issues when auto-patching fails.

[-]

Latlanc@reddit

Here we go again... Can we stop with the schizo shit? Linux user sees telemetry == THEY SPY ON YOU!!!!!

[-]

MairusuPawa@reddit

It's absolutely terrifying to see people as complacent with absolute bullshit as you are.

[-]

PerkyPangolin@reddit

Data point is a data point. Remember Cambridge Analytica?

[-]

Latlanc@reddit

Cambridge Nothingburgerica? Yeah, I remember.

[-]

linuxjohn1982@reddit

The Data Harvesting

A researcher named Aleksandr Kogan created a Facebook quiz app ("thisisyourdigitallife") that, when used, collected data not just from the person who took the quiz, but also from all of their Facebook friends, without those friends' knowledge or consent. This exploited a loophole in Facebook's API at the time. Around 270,000 people took the quiz, but data from an estimated 87 million Facebook users was harvested as a result.

The Sale to Cambridge Analytica

Kogan sold this data to Cambridge Analytica, a firm with ties to Republican political operatives and partly funded by billionaire Robert Mercer. This violated Facebook's terms of service, which prohibited selling user data. Cambridge Analytica used the data to build detailed psychographic profiles of voters — categorizing people by personality traits to target them with tailored political messaging.

Political Use

Cambridge Analytica claimed to have worked on:

The 2016 Ted Cruz presidential primary campaign
The Donald Trump 2016 presidential campaign
The Brexit "Leave" campaign (though the extent of their role was disputed)

[-]

Purgatide@reddit

Telemetry on its own? Sure, I'll give that to you.

Telemetry from a company that is owned by Microsoft? Telemetry in a tool that really shouldn't have it due to the information already being available to them elsewhere (/u/gplusplus314 said it better than I could)? I think that context alone should make anyone side-eye this, not just Linux users.

[-]