Live data from Hacker News

GitHub CLI 1.0

github.blog

171–180 of 221 posts

Re: GitHub CLI 1.0

#171
post #87

GitHub is killing it with these features. I wonder how long Azure Repos will survive on it's own.

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

I like that it works with Active Directory, so I don't need my developers to setup their own GitHub accounts to work.

Re: GitHub CLI 1.0

#172

Earlier quoted context omitted.

I get just as tired of reading this take as the next person, but I don't necessarily think we should do away with it - it'd be akin to ignoring history. I personally remain very uncomfortable with how massive GitHub has become and how ~99% of software development happens on the platform.

There isn't much lock-in yet though. If you wanted to move a project from github to gitlab, you could move the code over with a few commands. Open issues and stuff could be moved over with a script. There isn't much 'network effect' that means your project would die on other hosting.

This is classic "it could be built in a weekend" syndrome, and I think we're all intelligent enough on this site to know that it's simply not true.

Furthermore, technology isn't the lock-in - it's the network, which you can't drag as easily.

Re: GitHub CLI 1.0

#173

Earlier quoted context omitted.

This is one of my favourites, too! And combined with the alias functionality, you can do gh alias set pcw 'pr create --web' and then just use gh pcw to create a new PR. There's also sufficient smarts around forking or not, depending on write permissions on the upstream repo.

Do you run this command frequently enough to do an alias? I feel like it'd be better to just have the muscle memory of typing the actual command instead

Probably a few times a day? One nice thing about the alias is that it expands and takes more parameters if you want, like

    gh pcw --base=development
It's also super quick to set up an alias, so I don't see why not.

Re: GitHub CLI 1.0

#174
post #82
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 switched from Emacs to VSCode but I still use Magit to do rebases.

Re: GitHub CLI 1.0

#175

Earlier quoted context omitted.

Do you run this command frequently enough to do an alias? I feel like it'd be better to just have the muscle memory of typing the actual command instead

Probably a few times a day? One nice thing about the alias is that it expands and takes more parameters if you want, like gh pcw --base=development It's also super quick to set up an alias, so I don't see why not.

I used to have a lot of git aliases but then I became dependent on those and forgot the actual git commands that were lying underneath. So whenever I went to a new system I'd have to port my dotfiles or look up the git docs for what the commands were. If a colleague asked me "how do I do X" I had no clue and had to look in my bashrc. Nowadays I only add them if I do it many many times per day. Like "git commit -a -m" for example. I try to keep things as close to stock as I can

This type of alias seems on the fence for me, if was like 10x a day I'd definitely be on board but a few times a day is a gray area

Re: GitHub CLI 1.0

#176
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

This is awesome, but with all due respect I also wish git itself was also improved.

Goddamn merge commits, and always have to go googling "oh shit how do I erase the last commit" when I accidentally commit to master. It should at least spit out a warning if you created a branch and then try to commit to master. Git lfs and git-crypt should be a feature of the main product and not plugins. Files over a certain size should be transparently LFSed without some need to "track" them or install a plugin to fetch them. It's too hard to accidentally forget to encrypt something or LFS something. Gitignore is easy to screw up and accidentally commit a sensitive credentials file. And "git rm" also removes the file locally with no recourse -- that should not be the default behavior.

Also, the whole UX around submodules REALLY sucks ... is it git submodule update --recursive --init? git submodule init --update --recursive? git init submodule --recursive? I can't remember for the life of me. Why can't it auto-clone all submodules when you clone the parent repo, seeing as you kind of need them to do anything? The UX is so bad that I often just copy the contents of the repo instead of using submodules.

Re: GitHub CLI 1.0

#177

GitHub is killing it with these features. I wonder how long Azure Repos will survive on it's own.

We did some training with Microsoft last fall and the coordinator straight up told us that DevOps functionality was being duplicated in Github and that DevOps was being sunset eventually. He recommended using YAML for all Pipeline Development as they were trying very hard to ensure that it would be compatible but legacy pipelines would not.

Azure Repos and maybe Pipelines be sunset and replaced by GiHub equivalents, but they’d have a hard time sunsetting the task management (Boards) without first significantly expanding it in Github. Many swear by their hierarchical backlogs, custom column Kanban boards and complex reporting. GitHub issues is extremely simple in comparison.

Re: GitHub CLI 1.0

#178

Earlier quoted context omitted.

We did some training with Microsoft last fall and the coordinator straight up told us that DevOps functionality was being duplicated in Github and that DevOps was being sunset eventually. He recommended using YAML for all Pipeline Development as they were trying very hard to ensure that it would be compatible but legacy pipelines would not.

Azure Repos and maybe Pipelines be sunset and replaced by GiHub equivalents, but they’d have a hard time sunsetting the task management (Boards) without first significantly expanding it in Github. Many swear by their hierarchical backlogs, custom column Kanban boards and complex reporting. GitHub issues is extremely simple in comparison.

Zenhub[1] is a pretty popular UI on top of GitHub that fills that need quite nicely for my team

1 - https://app.zenhub.com/

Re: GitHub CLI 1.0

#179

Is this coming full circle: Git -> GitHub -> GitHub CLI?

CLI or not, it's centralized/siloed all the same. I'm sticking to Git.

Good point.

It never seemed like the distributed "selling point" of Git (and Mercurial et al) really caught on. I remember trying to extoll it's virtues to our team at the time (pre-Github). No one source of truth as such, just everyone swapping changes as needed. It's kind of ironic that Git's most popular incarnation is based upon a centralised model.

Is it just a case of the distributed workflow just not being that useful for most people? Beyond the obvious example of Linux kernel development, of course!

Post reply on HN