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?
GitHub CLI 1.0
171–180 of 221 posts
Re: GitHub CLI 1.0
#172Earlier 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.
Furthermore, technology isn't the lock-in - it's the network, which you can't drag as easily.
Re: GitHub CLI 1.0
#173Earlier 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
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
#174Earlier 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.
Re: GitHub CLI 1.0
#175Earlier 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.
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
#176Oh 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
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
#177GitHub 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.
Re: GitHub CLI 1.0
#178Earlier 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.
Re: GitHub CLI 1.0
#179Is this coming full circle: Git -> GitHub -> GitHub CLI?
CLI or not, it's centralized/siloed all the same. I'm sticking to Git.
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!