If you wish to leverage the advanced features of github, the CLI gives you direct access rather than rolling your own api client. git will always be a first class citizen at GIThub.. but how do you open, close, or comment on PRs with a standard git client?

Edit: The last part came across a bit snarky, but I’m trying to stimulate the thought process. Such as leveraging GitHub Actions to automate all aspects of PRs via gitops instead of using the GitHub client. Many ways to avoid dependence of the CLI!

As another commenter pointed out, we're at extend part of embrace, extend, extinguish. This part is just making Github tools work easier than non Github.

In extinguish phase - Git won't prevent GitHub from rejecting a commit if it doesn't contain <TrackingMethodSignature>.

That sounds very much like the "extend" part of the process.

It feels like an open source standard on top of git that defines how to do this stuff would be helpful to reduce lockin. I wonder if Fossil or Gitlab have something.

I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy.

> There may be a time where you must use Github CLI instead of a "standard" git client to interact with Github projects

So we're accusing MS of a slippery slope based on a phrase from 25 years ago, which there is absolutely zero proof or indication of them pursuing in the last decade (at least).

When GitHub show the _slightest_ inclination to do anything of the sort, I will be standing there with you, screaming blue murder. As of right now, they're progressing the development of git, "embracing" the open standards that have been developed (lfs being exemplary) and have shown absolutely zero signs of extending git in incompatible ways. See elasticsearch [1] for what "extend" _actually_ looks like.

> Right now they have embraced and are extending (such as with Github CLI).

If they _hadn't_ embraced, people would be complaining that GH are forcing non-open standards to be used. I firmly disagree that the GH issue tracker and pull request management are an "extension" of git. They have nothing to do with git whatsoever.

[0] https://news.ycombinator.com/item?id=28149098 [1] https://news.ycombinator.com/item?id=28110610

> I made this comment elsewhere [0], but by this logic anyone who builds an ecosystem for an open source tool should be accused of the EEE strategy.

Yes, of course.

Why, did you somehow think otherwise?

In practice, it doesn't matter what an "actual" extension looks like, but how your product is viewed by customers, because those are the ones you want to lock in. And judging by HN comments, to very many people, Git means Github, making it an extension, if not outright a synonym.

And their extending has nothing to do with open standards, which is worrying due to the potential to create lock-in.

By that logic, anyone who builds a product around an open standard is guilty of EEE. A web browser that implements a sync feature, an XML editor that implements syntax highlighting , an RSS reader that implements link previews all "embrace" open source standards and "extend" their core open standards with non-standard features, which is _exactly_ what github have done. They have been excellent players in the git ecosystem.

I think this conundrum can be broken up by noticing how pervasive one extension is. A feature that has become identical with the core product in the eyes of a layman is problematic in the same way as thinking "IE6" is the same as "the web". If there's no awreness of choice, then the only outcome is further lock-in.

Implementing "sync" on its own doesn't matter that much, because few people think "sync" is a defining feature of the web standards, or that preview is an inherent part of web feeds. The awareness of alternatives still exists (I hope).