Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub CLI 1.0

github.blog

Post reply on HN
Print view View original

131–140 of 221 posts

Re: GitHub CLI 1.0

#131

Post by mroll »

DvdMgr wrote: post #19
mroll wrote: post #16

Oh wow this is great. I’ve been wanting an org mode integration with GitHub for a while, and this tool might make it easy enough for me to hack together this weekend. Basically I want to be able to pull up a buffer with a list of issues assigned to me and copy them into my org mode todo list

You can do this using Forge within Magit already! And it also works for Gitlab: https://magit.vc/manual/forge/

Haha of course this already exists! Thanks a lot for the pointer, I will for sure start playing with it this week :)

Re: GitHub CLI 1.0

#132

Post by gumby »

chungus wrote: post #82
DvdMgr wrote: post #19

Earlier quoted context omitted.

You can do this using Forge within Magit already! And it also works for Gitlab: https://magit.vc/manual/forge/

Been meaning to try Forge, thanks for the reminder. Honestly, Magit alone is enough reason to use Emacs. Projectile is a close second for me.

I find projectile too chatty and distracting none thing I like about emacs is that I can focus on what I’m working on.

Re: GitHub CLI 1.0

#133

Post by narwally »

ljm wrote: post #110
narwally wrote: post #108

Earlier quoted context omitted.

I've been using Emacs for a decade and still have never had to write a single package of my own. Every time I have a good idea, someone else has already implemented it.

I've written a few specialisms that couldn't really be open-sourced. e.g. wiring up inf-ruby and internal dev tools to open up a rails console in dev, or generate a jwt from the auth server in the cluster. The only package I've been ultimately responsible for is the Gruvbox theme[^1], but that was very quickly handed over to other emacsers :) I still find it a joy to write and it's one of my more preferred rabbit hol…

Oh wow, I used to use that theme. Thanks for making it. Yeah, most of the elisp I write is mostly just glue code, not something that makes sense to package and distribute.

Re: GitHub CLI 1.0

#134

Post by wilg »

SergeAx wrote: post #126

Watch those hands, we are at the "extend" phase [0]. Then there will be bait-and-switch move, and voila, Github is not working with git client, just with their own shell. [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

How do you know the difference between being in an EEE scenario versus just being in a scenario where people keep working on their product?

Re: GitHub CLI 1.0

#135

Post by dkarlovi »

jgillette wrote: post #94
boogies wrote: post #87

Earlier quoted context omitted.

Never heard of Azure Repos before. Do they have any unique features that could be merged into Github?

I believe that Actions was a port from Azure DevOps ( https://azure.microsoft.com/en-us/services/devops/?nav=min ) so it does seem the teams are working together to improve the products.

IIRC it was Azure pipelines.

Re: GitHub CLI 1.0

#136

Post by albatruss »

narwally wrote: post #108
DvdMgr wrote: post #19

Earlier quoted context omitted.

You can do this using Forge within Magit already! And it also works for Gitlab: https://magit.vc/manual/forge/

I've been using Emacs for a decade and still have never had to write a single package of my own. Every time I have a good idea, someone else has already implemented it.

Consider donating -- if you're a software engineer, acknowledge the value of your own time!

Re: GitHub CLI 1.0

#137

Post by coliveira »

SergeAx wrote: post #126

Watch those hands, we are at the "extend" phase [0]. Then there will be bait-and-switch move, and voila, Github is not working with git client, just with their own shell. [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

And in a few iterations they will label git as "legacy".

Re: GitHub CLI 1.0

#138

Post by whatgoodisaroad »

wilg wrote: post #134
SergeAx wrote: post #126

Watch those hands, we are at the "extend" phase [0]. Then there will be bait-and-switch move, and voila, Github is not working with git client, just with their own shell. [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

How do you know the difference between being in an EEE scenario versus just being in a scenario where people keep working on their product?

When the open components that allow free interoperability with GitHub's competitors are replaced with proprietary components that don't.

Re: GitHub CLI 1.0

#139

Post by coliveira »

wilg wrote: post #134
SergeAx wrote: post #126

Watch those hands, we are at the "extend" phase [0]. Then there will be bait-and-switch move, and voila, Github is not working with git client, just with their own shell. [0] https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...

How do you know the difference between being in an EEE scenario versus just being in a scenario where people keep working on their product?

Just look at history.

Re: GitHub CLI 1.0

#140

Post by clarle »

I tried it today, and it's pretty neat, but without the ability to write comments inline, it's not super useful for any actual pull request reviewing work.
Post reply on HN