[HN Gopher] GitHub CLI 1.0
___________________________________________________________________
GitHub CLI 1.0
Author : todsacerdoti
Score : 493 points
Date : 2020-09-17 13:03 UTC (9 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| kkapelon wrote:
| What about https://hub.github.com/ ?
| monkey_slap wrote:
| Check out https://github.com/cli/cli/blob/trunk/docs/gh-vs-
| hub.md
|
| FWIW gh is built by some of the same people that built &
| maintain hub.
| andra_nl wrote:
| Hey, thanks for sharing. I was wondering about hub vs GH.
| kkapelon wrote:
| Thanks. I think this info should become part of the blog post
| IMHO
| pkamb wrote:
| I use `hub sync` multiple times per day. Essential tool.
|
| It's the only way to stay sane in a repo with multiple other
| developers merging PRs. Updates all of your branches in the
| background to the current remote version.
| andra_nl wrote:
| Damn, I should RTFM, 'cause that sounds super useful!
| mumblerino wrote:
| For the time being, hub still mostly helps with git operations,
| in fact it can be used as a git wrapper/replacement since it
| supports all of git's commands.
|
| gh on the other hand seems to very specifically work on
| GitHub's non-git features, like Issues, PRs, repositories.
| RMPR wrote:
| IME for non-git features hub is very slow iirc it's written in
| Ruby
| caycep0llard wrote:
| hub has been pure Go for a long time now.
| forrestthewoods wrote:
| Embrace - complete
|
| Extend - in progress
|
| Extinguish - todo
| algorithmsRcool wrote:
| GitHub is killing it with these features. I wonder how long Azure
| Repos will survive on it's own.
| cptskippy wrote:
| 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.
| alkonaut wrote:
| 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.
| meesles wrote:
| 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/
| Scarbutt wrote:
| And Golang is killing it for these kind of applications.
| narwally wrote:
| I haven't done much beyond dip my toes in Golang so far, but
| I did start moving my blog over from Jekyll to Hugo last
| week; Man do I love just being able to install a single
| binary and then get to work. Python, Javascript, and Ruby
| have a lot of nice packages, but I always have to futz around
| with the language itself to use them effectively. It's
| probably a bit easier to get a project up and running in a
| scripting language, but any development time that is saved
| just gets passed on to the users as we have to install a ton
| of npm packages or try to fix our gem dependencies.
| rhizome wrote:
| Are dependency problems with Hugo modules not possible?
| narwally wrote:
| I'm sure there are, but I haven't needed to use any
| modules so far, so I have no perspective on what kind of
| challenges they present. But with Jekyll you could get
| into dependency issues just trying to go through the
| tutorial and launch a blank template of a site. You
| didn't need any extra functionality on top of Jekyll to
| begin to dealing with dependencies.
| boogies wrote:
| Never heard of Azure Repos before. Do they have any unique
| features that could be merged into Github?
| jgillette wrote:
| 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.
| dkarlovi wrote:
| IIRC it was Azure pipelines.
| moron4hire wrote:
| I like that it works with Active Directory, so I don't need
| my developers to setup their own GitHub accounts to work.
| DavidKarlas wrote:
| When reviewing PR, it has nice file/folder tree on left side,
| which is far superior compared to scrolling over 10+ files
| without context on Github, I hope Github gets this soon...
| bbatha wrote:
| There's a browser plugin called Octotree which does a
| pretty good job of this, but I'd prefer it to be builtin.
| clarle wrote:
| 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.
| jordanlewis wrote:
| I agree. I wrote a tool that does inline PR commenting on the
| command line. I hope they add something like this to gh over
| time.
|
| https://github.com/jordanlewis/re
| nixpulvis wrote:
| name me one feature this has that I didn't have 3 years ago with
| `hub`?
| pickledish wrote:
| Hmm, anyone know the name of the font they're using in the
| pictures? Closest I was able to find was anonymous pro, but
| that's not quite it
| naveguese wrote:
| The monospace font in Apple's San Francisco family, SF Mono.
|
| https://github.com/lionsharecapital/lionshare-desktop/tree/m...
| pickledish wrote:
| Ah yeah, so it is! Good eye :)
| renewiltord wrote:
| Very nicely done. The package installation process for Ubuntu is
| good. Thank you.
| yarrel wrote:
| Or git, as it's known.
| dberg wrote:
| Is this proof that regular git commands are too difficult to use?
|
| I also wonder what this is going to do for folks not using Github
| as now CLI users are going to "unlearn" all their traditional git
| commands.
| Iwan-Zotow wrote:
| How you could create issue with git? Project on github is much
| more that just git repo
| rolfvandekrol wrote:
| It seems like this is not a CLI for git, but for the Github
| specific stuff, such as issues and pull requests.
| pbalau wrote:
| No, is a complement. See [0]. Basically allows doing from cli
| things you could only do from the UI before (without writing
| your custom scripts).
|
| [0] https://cli.github.com/manual/index
| cfors wrote:
| It's not a replacement for git, its to interact with the GitHub
| UI over the command line.
|
| There are 3 main commands from the CLI you can issue:
| gh CORE COMMANDS issue: Create and
| view issues pr: Create, view, and checkout pull
| requests repo: Create, clone, fork, and view
| repositories
|
| I still use the git cli and the github UI, but sometimes just
| view open PR's from the my terminal if I'm already in there.
| Galanwe wrote:
| Honestly the doc make it pretty unclear.
|
| Some commands seem to be purely github related, which make
| sense, some others seem to overlap with just plain git.
|
| > Clone the repository you want to work with using gh repo
| clone owner/repo
|
| Like, what does this do apart from a regular git clone? Why
| is this necessary? I guess it additionally stores some meta
| information so that other "gh" commands know which repo they
| are on. This should have been a separate command IMHO to
| leave the regular git clone alone. Something like "git clone
| ssh://github.com/foo/bar" followed by "gh init foo/bar".
|
| > When you've finished adding that feature or fixing that
| bug, use gh pr create
|
| Same goes here. Why overlaying git commands? I would have
| expected to just push my branch, and then call something like
| "gh pr create <my branch> <target branch>"
|
| > And your teammate can check out your pull request using gh
| pr checkout 1337
|
| Same remark again and again, what does that do apart from
| checking out a branch? Why the overlay?
|
| > view the diff with gh pr diff
|
| So what's wrong with "git diff <target>..<source>"
|
| > gh pr merge
|
| Come on.. "git co <target> ; git merge <source>" needs to be
| overplayed?
|
| > gh release create [tag name]
|
| Oh sure, let's overlay git flow as well.
|
| I mean overall the tool looks cute and all, but magic
| overlays is a no no for me.
| pbalau wrote:
| Convenience.
|
| > Like, what does this do apart from a regular git clone?
| Why is this necessary?
|
| You can't see a difference between ```gh repo clone
| owner/repo``` and ```git clone
| git@github.com:owner/repo.git```?
|
| Also:
|
| > Something like "git clone ssh://github.com/foo/bar"
| followed by "gh init foo/bar"
|
| What's there to "init"?
|
| > Same goes here. Why overlaying git commands? I would have
| expected to just push my branch, and then call something
| like "gh pr create <my branch> <target branch>"
|
| From the docs: "When the current branch isn't fully pushed
| to a git remote, a prompt will ask where to push the branch
| [...]"
|
| > Same remark again and again, what does that do apart from
| checking out a branch? Why the overlay?
|
| It resolves the pr # to the corresponding branch name,
| probably git fetch and checkout. Why should I have to know
| the irrelevant piece of information that is how you named
| your branch?
|
| > So what's wrong with "git diff <target>..<source>"
|
| How do you find out the target and source hashes? Another
| piece of convenience.
|
| > Come on.. "git co <target> ; git merge <source>" needs to
| be overplayed?
|
| And this is wrong. This merges source in target __locally
| __, ```gh pr merge``` merges it remotely. You can be Linus
| Torvalds, you are not going to push to my master branch.
| ape4 wrote:
| Yeah, I wonder if `git` could be improved based on this.
| georgedrummond wrote:
| No doubt the intent of this tool is to tightly couple your
| development flow to GitHub/Microsoft.
|
| Makes switching to other vendors more painful further down the
| line.
| algorithmsRcool wrote:
| I don't understand this mentality. Git itself doesn't provide
| a way to interact with PRs or issues on GitHub.
|
| This utility does.
|
| If you are uncomfortable with using GH to manage issues and
| PRs you shouldn't probably shouldn't be using GH.
| maccard wrote:
| That's a fairly cynical take. How is this any worse than
| offering an API?
|
| It's open source [0], there's nothing stopping you hooking it
| up to Gitlab, or pointing it at jira.
|
| [0] https://github.com/cli/cli
| [deleted]
| djsumdog wrote:
| I've used ghi before just for issues:
|
| https://github.com/stephencelis/ghi
|
| It's pretty nice. I like seeing these features supported
| officially (I think hub supported many of these unofficially for
| years).
|
| What tools are there like this for Gitlab? I remember struggling
| just to find a decent CLI for their issue tracker.
|
| All my new stuff is on Gitlab and I prefer Gitlab since if I ever
| want to, I can always just management my own instance and migrate
| to it. No such options with Github.
| KarimDaghari wrote:
| If you use VSCode they have a pretty decent extension (GitLab
| Workflow)
| mroll wrote:
| 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
| DvdMgr wrote:
| You can do this using Forge within Magit already! And it also
| works for Gitlab: https://magit.vc/manual/forge/
| iterati wrote:
| Forge is great. Magit is such an enjoyable plugin already,
| but integration with PRs and issues takes it to the next
| level.
| Kalekoa wrote:
| Yes! Thank you for this tip
| mroll wrote:
| Haha of course this already exists! Thanks a lot for the
| pointer, I will for sure start playing with it this week :)
| RMPR wrote:
| Now this is awesome.
| chungus wrote:
| 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.
| praveenperera wrote:
| I switched from Emacs to VSCode but I still use Magit to do
| rebases.
| gumby wrote:
| I find projectile too chatty and distracting none thing I
| like about emacs is that I can focus on what I'm working
| on.
| narwally wrote:
| In what way do you find it too chatty? That hasn't been
| my experience, but I do use a pretty small subset of it.
| Are you using it on its own, or with helm/ivy?
| bloopernova wrote:
| Can you recommend any good articles or howtos on Forge and
| Projectile?
| narwally wrote:
| 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.
| albatruss wrote:
| Consider donating -- if you're a software engineer,
| acknowledge the value of your own time!
| narwally wrote:
| I donate little bits here and there when I can, but I'm
| unfortunately not in financial position to give what I
| think the maintainers deserve. Instead I try to submit
| documentation patches to projects whenever I find myself
| digging through the source code trying to answer a
| question the docs didn't make clear.
| ljm wrote:
| 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 holes to dive into. Maybe one day there'll
| be something more to share :)
|
| [^1]: https://github.com/mrleedev/emacs-gruvbox-theme
| narwally wrote:
| 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.
| dheera wrote:
| 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.
| 0xmohit wrote:
| Wonder if this would lead to the end of hub
| <https://hub.github.com>.
| BFdes wrote:
| I think the creator of Hub works for GitHub, possibly on the
| CLI IIRC.
| jrochkind1 wrote:
| hub was also a github project. Somewhere there is a blog post
| or something explaining the relationship of this to hub --
| basically, they wanted to start over with new architecture and
| new thoughts, and a more clear organizational commitment to it
| (even though hub is at `github/hub`, it is github-owned code).
|
| There is no particular plan to phase out hub, but once github
| CLI covers enough features, I'd expect people to switch over to
| it.
| staller wrote:
| They do not treat hub as an official github project and rather
| an unofficial open source project that they don't plan to do
| away with
|
| They have a document where they expand on this:
| https://github.com/cli/cli/blob/trunk/docs/gh-vs-hub.md
| SergeAx wrote:
| 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...
| tus88 wrote:
| And wait until they claim it is to "improve the user
| experience" because they care about their users so much they
| need to protect them from the free and familiar tools they are
| used to.
| coliveira wrote:
| And in a few iterations they will label git as "legacy".
| rasengan0 wrote:
| This may be relevant:
| https://news.ycombinator.com/item?id=24420307
| mikorym wrote:
| I think the simple way of passive resistance is calling it
| "Microsoft GitHub".
| SergeAx wrote:
| Good idea, gonna use it, thanks!
| chadly wrote:
| This is a tired take. Can a company not legitimately improve
| their product/offering without this being accused at them?
|
| If you are referring to GH being owned by MS now, it's 2020 for
| godsake. Can we move on from our fathers' trauma? MS has been
| damn good lately in support of developers and developer tools.
| whatgoodisaroad wrote:
| To me, this isn't a real counterexample, even at the height
| of MS's EEE, it was never at the expense of developer
| tooling, it was at the expense of openness. In fact,
| improving developer experience was the primary lever MS used
| to achieve it.
| Klonoar wrote:
| 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.
| cycloptic wrote:
| Looking at the history in the wikipedia article that was
| linked in the GP post, none of the executives who used that
| phrase are with the company anymore.
| londons_explore wrote:
| 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.
| Klonoar wrote:
| 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.
| rhizome wrote:
| Subtract the bare assertions and questions and your argument
| boils down to "it is $current_year, and Microsoft has been
| good lately." Which, I think you might agree, doesn't contain
| a lot to convince someone who remembers the bad old days.
| wilg wrote:
| 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?
| whatgoodisaroad wrote:
| When the open components that allow free interoperability
| with GitHub's competitors are replaced with proprietary
| components that don't.
| coliveira wrote:
| Just look at history.
| croo wrote:
| Great news but my first thought was that it's hard enough for
| juniors to grasp the difference between git and github. Now they
| will be even more confused... :]
| shaky wrote:
| I don't understand the appeal of using a cli to manage commits,
| branches, remotes, merges with conflicts, and so on. To me all
| these things are so much better internalized and understood when
| presented visually. Git GUIs are aplenty (Sublime Merge being my
| latest discovery, SourceTree before that) and generally really
| good. Combined with the already amazing GitHub web GUI, it's a
| wonder what use case is better served by sticking to the cli,
| other than this misplaced notion that it's what the cool kids are
| doing.
| jaster wrote:
| Better scripting / automation maybe? I don't have any specific
| example in mind right now, but being able to pipe things
| together with other utilities could make for interesting
| applications, and is easier than having to interact with a REST
| API.
| ridv wrote:
| I have an open source project that moved from using Jira to
| track issues and changes to Github. Before, when the project
| made a release, it would fetch info from Jira to create a
| changelog.
|
| With this tool, I was able to do something similar using
| Github as the source of information instead[1].
|
| I fetch the info using the gh tool, output the result into
| json, and use a python script to format the output which
| results in a decent looking automatically generated
| changelog[2].
|
| It's not the most exciting thing, and I could have probably
| achieved it in a different way using the GraphQL API
| directly, but for the needs of the project this fit the bill
| and let me get on with the release.
|
| [1] https://github.com/aurora-
| scheduler/aurora/blob/master/build...
|
| [2] https://github.com/aurora-
| scheduler/aurora/blob/master/CHANG...
| Cthulhu_ wrote:
| Yeah, CI solutions can use this command instead of having to
| write and maintain their own github API interfacing, for
| example.
| ocdtrekkie wrote:
| Indeed, a project I work on has a release script which tags a
| release and all and currently uses a third party tool for the
| GitHub interactions. Now we can use the first party GitHub
| CLI commands instead.
| jkubicek wrote:
| It's worth installing the CLI just for a single command:
|
| `gh pr create --web`
|
| Saves me having to push my current branch, navigate to the repo
| page, hit the "create PR" button, etc.
| bewuethr wrote:
| 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.
| jhatemyjob wrote:
| 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
| bewuethr wrote:
| 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.
| jhatemyjob wrote:
| 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
| ben_e wrote:
| This is the main reason I'm installing - I can build this
| into my editor pretty easily.
| jillesvangurp wrote:
| Yes, that's what I do as well. I also have the old hub
| frontend for git installed. The idea is that you simply alias
| git to hub and then you get a few extra commands.
|
| My favorite is "git browse", which opens a browser for the
| current repo & branch. There are a few other commands that
| are probably useful but that I don't really do much with.
| steveklabnik wrote:
| These days when I push a branch, github gives a URL in the
| response that I can click from the terminal to open a PR. It
| is indeed very good.
| [deleted]
| dvlsg wrote:
| That is pretty nice.
|
| I've been doing `git push -u origin HEAD` and then using my
| mouse to click on the "go here to create a PR" link that gets
| printed, which isn't too bad. Takes you right to the page
| where you can review the changeset before opening the PR. If
| I'm not actually ready to open a PR by the time I push
| upstream, I just open a draft instead.
| Pandabob wrote:
| Thanks for this, will start using it.
| mikepurvis wrote:
| Yeah this is huge-- I used to use `hub` for this one thing as
| well. The alternative is even worse if you cloned from a repo
| you don't have push access to, so your first step is going to
| the web UI, creating the fork, switching the remote on your
| clone, and then _finally_ pushing and creating the PR.
| juped wrote:
| What's amazing about the Github web GUI?
| swagonomixxx wrote:
| It's not utter garbage (at least not yet).
| juped wrote:
| I'm not sure this is the case! In fact, I strongly suspect
| that its inability to display logs or diffs correctly has
| contributed to the widespread developer confusion with
| respect to Git, especially since there are many people out
| there who think, implicitly if not explicitly, that Git and
| Github are one and the same.
|
| You know how a lot of people think merge commits (an
| important keystone in how easy Git makes it to read and
| write meaningful history) are inherently "confusing" or
| "messy", and try to avoid creating them? Well, if you look
| at them in Github's awful log interface, they sort of are!
| This doesn't seem like the fault of those developers, and
| it's not Git's fault, since it ships with powerful command-
| line and GUI tools for making sense of things.
| httpsterio wrote:
| a CLI is scriptable and automateable, so there's that at least.
| How about "find all related issues and close based on the
| commit message and push to production if it's an urgent fix"
| etc
| ssully wrote:
| I have to agree. I used the CLI for years until a coworker
| showed me Githubs desktop app. I was hesitant at first, but it
| makes managing multiple projects so much easier.
| _ph_ wrote:
| Besides the obvious advantages of command line user interfaces
| for a lot of use cases, I am not aware of any really good Git
| GUI. Can you name any for Linux or Mac OS? Commercial would be
| ok, as long as it can be installed locally and does not require
| a server.
| ufo wrote:
| On Linux I like using gitg. I think it is "good" in the sence
| that for the tasks it can do (mostly viewing history) the UI
| is well though out and simple to use. However, it can't do
| more advanced tasks so it might not be what you are asking
| for.
| _ph_ wrote:
| I am using it too for visualizing the history, but the
| version I use doesn't do pushes yet.
| andrewl-hn wrote:
| SourceTree is very good and free. I use it for:
|
| 1. Selecting specific lines for a commit. 2. Stashes
| management 3. Rebasing branches, cherry picking commits.
|
| It is possible to do a lot more with it, but for the most
| other operations I use command line or GitHub UI.
| gibolt wrote:
| I use GitKraken, it is great!
|
| https://www.gitkraken.com/
| _ph_ wrote:
| That to my knowledge is server-based.
| ohgodplsno wrote:
| It does not require a server to run.
| _ph_ wrote:
| Thanks, then I will give it a try, when I had looked on
| the web page the last time I got the impression it was a
| server based application and required an account on their
| servers.
| _ph_ wrote:
| Thanks to the one downvoting me - what in my comment
| justifies a downvote? If my statement is wrong, I would
| certainly be interested in a correction.
| ricksharp wrote:
| vscode with 'git graph' extension is the best git toolset
| ever.
|
| My favorite feature is ctrl+click 2 nodes in the git tree and
| immediately see file level diff which I can explore in
| vscode's diff viewer.
|
| For work, we use git flow with github PR (which I do on
| github website) and always work in feature branches. I am
| able to navigate git like a pro, cherry picking etc as needed
| without a problem. It even works well with git submodules.
|
| If something goes unexpected, git graph is the best tool to
| figure out what happened and to be able to repair it.
|
| Also, vscode handles merge conflicts in a way I can actually
| understand and correct without it slowing me down.
| hemogloben wrote:
| Synvento's SmartGit (commercial)[1] is excellent and fully-
| featured; uses a license file for registering so I don't
| believe it requires a server.
|
| [1] https://www.syntevo.com/smartgit/
| _ph_ wrote:
| We actually licensed SmartSVN, which was a life saver for
| its version tree display. For most operations, we tended to
| use the command line nevertheless.
| rs999gti wrote:
| I like GitHub desktop
| addicted wrote:
| I largely use the CLI and I still manage conflicts and diffs
| visually (in plain git), by triggering a visual diff
| application from the CLI when I prefer doing so.
|
| The GIT cli has the option to use an external diff helper if
| you prefer.
| chousuke wrote:
| I've never felt the need to visualize git scenarios; they just
| aren't all that complicated most of the time, though I can see
| how it might be useful to open a graph viewer if you have a
| tricky merge to sort out.
|
| For me, being able to just note down in a text file an exact
| trace of what I've done is the gist of why CLIs are superior
| for my use. How do you even begin to keep track of what you do
| in a GUI? You could record video, but the information density
| is way too low for it to be useful, and it's worthless for
| automation.
|
| A lot of my stuff gets automated by me first doing stuff
| manually, recording what I do in a script, and next time just
| running said script. That's just flat out not possible with
| most GUI tools, and even if it were, it's too cumbersome to be
| worth doing.
| whoisjuan wrote:
| Without a CLI you can't automate. (I guess you could, but it
| will be a pain in the ass)
| bewuethr wrote:
| There was the option to use curl and the GitHub API, but the
| CLI wraps that very conveniently in the "api" subcommand.
| azangru wrote:
| Huh? Github actions have been around for over a year, and
| Github webhooks since I can't remember when.
| whoisjuan wrote:
| Not really sure what you're talking about. Not everything
| you automate on GitHub happens in the context of a CI
| pipeline like in GitHub Actions. There are many cases for
| small scripts where you just need to execute a couple of
| commands.
| GormHouj wrote:
| Yeah, and this is the correct way to automate anything
| relating to github. Their API is insane.
| hjdarnel wrote:
| ...unless you use their CLI wrapper over the API (as in
| this post) :)
| greggman3 wrote:
| Probably because the GUIs are always missing something.
|
| today I wanted to see the commit history and changes of a
| single file. I tried for 20 minutes to figure how to do that in
| sublime merge some of that searching online. Failed. Used the
| command line like I probably should have in the first place.
| tssva wrote:
| It has nothing to do with being a cool kid. No two people are
| the same. How you best process information may not be how
| someone else best processes information. Neither is right or
| wrong they are just different Everyone deserves to have tools
| available which fit how their brain best processes information.
| GiorgioG wrote:
| Git GUIs simply don't provide the power/flexibility the CLI
| provides without introducing a UI with a gazillion options.
| I've tried many (GitKraken, Tower (paid for it too!),
| SourceTree, VS's integration) and I've always gone back to the
| CLI.
| machello13 wrote:
| Depends on how well-designed the app is. GitUp has been my
| go-to for years, after trying almost every other app out
| there. It offers a bunch of powerful features exposed mostly
| through right-click menus and single-button shortcuts. The
| only reason I ever go to the command line (and I used to be a
| religious command-line-only Git guy) is because GitUp freezes
| on extremely large diffs, which one of my projects has a lot
| of.
| sixstringtheory wrote:
| GUIs are discoverability nightmares though, as you
| describe. CLIs are the only place you can do a "man git |
| grep thing". On macOS there's [?] + ?, but that has never
| covered all the content in a man entry for the related CLI,
| IME.
| judofyr wrote:
| There are a bunch of examples which I find very useful with the
| CLI: Creating new repos (gh repo create), opening the repo in
| the browser (gh repo view), checking out PRs when you have the
| ID (gh pr checkout ID), diffing the currently checkout PR
| against the base (gh pr diff).
| aosaigh wrote:
| How about when you already do most of your development on the
| command line? In web development anyway, most frameworks,
| servers and tools are CLI only so you are already on the
| command line for the most part. It's far quicker to do a quick
| commit there and then rather then move to a GUI.
|
| That said, I use both. Most of my commits etc. are on the CLI
| but I still switch to a GUI if I want to browse the repo or see
| more detailed diffs etc.
| jacurtis wrote:
| Exactly this. I use the GitHub CLI and website interchangably
| throughout the day. When making commit messages, I generally
| always link a commit to an issue. So the end of a commit
| message will generally say "Resolves #281" or "Fixes #433" or
| "See Issue #218" or whatever.
|
| I usually need to double check open issues when making these
| messages and since I am already writing commits on the
| command line, having a split terminal or tab that can pull up
| active commits with a single line command and see them in a
| concise and clean format, it is super helpful and fast.
|
| If you are already working in the command line all day long,
| then it makes perfect sense to have access to GitHub in the
| command line as well.
|
| Another benefit is that most IDEs will have direct terminal
| access within the IDE, which means you can get relevant
| GitHub details about your project from within the IDE via the
| terminal, without needing to leave the IDE.
|
| Lastly, the CLI version is far more concise and simple
| compared to the web version.
|
| I am not hating the web version. I still use the web version
| plenty. But it is just another useful tool in the quiver that
| has plenty of use cases and simplifies workflow.
| high_priest wrote:
| If you are not on Linux, please try Fork. It's plenty fast and
| very robust, I have fallen in love with it on first sight.
| Aperocky wrote:
| cli should be the basis of everything.
|
| There can be UI and sometime that's helpful, but all action
| contained therein will be available on cli, just because that's
| exactly what the UI calls.
| SippinLean wrote:
| VS Code does everything Sublime Merge does, for free
| solatic wrote:
| Official CLI tools make it much easier to build automation with
| shell scripts.
|
| One example that comes to mind - we used hub to hack together a
| quick security feature that errors out our CI/CD pipeline
| (which runs shell scripts) if there are any open PRs that are
| labeled "security" (i.e. Dependabot opening a PR to update a
| vulnerable library), which forces developers to keep their
| dependencies up-to-date in order to deploy into production.
|
| GUI tools don't work as part of CI/CD pipelines.
|
| Libraries in higher-level languages (e.g. Python) force you to
| make sure that there's a library for every tool that you work
| with - if a specific tool is missing a Python library, then you
| have to deal with that yourself. Shell scripting is much more
| productive for gluing multiple sets of tooling together, as
| long as the shell scripts remain of a maintainable length.
| grugagag wrote:
| Scripting and shortcuts are very useful. To each their own but
| doing repetitive tasks in a GUI is prone to errors and boredom
| fouric wrote:
| The things you mentioned _are_ better when presented visually.
| Visual representations leverage the visual processing system of
| the human brain, and for graph-like data are near-objectively
| superior to linear textual representations.
|
| However, you can approximate visual representations of these
| things in a CLI - `git log --graph --pretty=oneline --decorate
| --abbrev-commit` will use ASCII characters to draw the DAG of
| commits.
|
| Moreover, the GitHub web GUI is not "amazing". It's _tolerable_
| as far as web UIs go, but it 's missing a lot of keyboard
| shortcuts (and none of them are customizable), has no built-in
| extensibility (the fact that you can inject your own scripts
| and stylesheets is a hack only at the display level, and an
| impractical one at that), EDIT: isn't scriptable, and is
| incredibly resource-intensive relative to a native application.
| The GitHub CLI allows you to manage the non-git parts of GitHub
| from the command-line (and make your own GitHub native client
| by extension) - which is desirable, given the above.
| juped wrote:
| gitk comes with Git - it's not perfect but it beats ascii
| art.
|
| I don't think the GH web interface is even tolerable. Even
| Bitbucket, which really sucks, has a better one...
| munchbunny wrote:
| It's more about automation than about end-user (developer) UI.
| CLI gives you a simple way to automate tooling for your team's
| processes (simpler than writing code to call into REST API's),
| and it's code, so you can maintain it as code and not some set
| of configurations on a UI somewhere.
| afarrell wrote:
| > better... understood when presented visually
|
| Often true for me as well. I like `tig`.
|
| > What use case is better served by sticking to the cli?
|
| Good question. Knowing the "why" of things is important. My
| answers:
|
| 1. Focus - Opening a browser and clicking around takes more
| patience. It tempts me to go update my company's internal
| documentation about something irrelevant to my current task.
|
| A CLI lets you pipe things to grep which lets you focus on
| specific information you care about.
|
| 2. Memory - I can write aliases to help me remember my common
| workflows.
|
| 3. Automation - I can have a script check PRs for me. This
| reduces context switching and enables greater focus and
| productivity.
| joppy wrote:
| 1. Can be addressed by using a GUI which is not on the
| internet, for example SourceTree, the git interface in
| IntelliJ, probably many more.
|
| 2. Is often unimportant if the GUI tool can make common
| workflows one or two clicks.
|
| 3. Having the CLI tools to automate stuff is great, but is
| not necessarily the best way to have an interactive session
| with a repository.
|
| Some of the things I like about graphical interfaces for Git:
|
| - The information density is usually (depending on the
| program) great - I can see local branches, remote branches,
| commits and tree diagram for the selected branch, all in less
| space than a terminal usually takes up.
|
| - A bunch of actions are available by right-clicking on a
| relevant item, so I don't have to remember commands and
| command-line flags etc and I can just get on with things.
|
| - Some actions like "show me the diff between these two
| commits" are SO much easier that they become a viable way of
| working.
| [deleted]
| Cthulhu_ wrote:
| Speed and overhead are both areas that should get a lot more
| focus nowadays; the Github desktop app along with a ton of
| other applications are Electron / webapps, each one adding a
| number of always-active processes, complex and expensive
| rendering, script execution, and a ton of memory usage, which
| do add up over time. I mean a lot of developers will have two
| or three Electron apps open right now; Slack and / or
| Discord, VS Code, Notion, and a bunch more in their browser
| of choice.
| [deleted]
| sigwinch28 wrote:
| This is worth it just for `gh repo create`
| akx wrote:
| I'd been using `hub create` for several years now...
| sigwinch28 wrote:
| I'll admit that the only time I heard of the GitHub CLI was
| last week when I thought to myself "it's really annoying
| going to the website every time I just want to push a new
| repo"
| jrochkind1 wrote:
| I use the older `hub` for only one command, but it's not
| that one! Instead, I use it for opening a PR from the
| command line. Since my work generally consists of making
| feature branches and PR'ing them, I use `hub pull-request`
| sometimes multiple times a day. Huge time saver.
| anderspitman wrote:
| Extend
| Shared404 wrote:
| Is there an advantage to using this over the standard git cli
| tool?
|
| It seems kinda like making a cli tool for a web interface for a
| tool. I guess I'm just missing something.
|
| Edit: Spelling.
| pbalau wrote:
| Yes, you are missing. This is GitHUB cli, not git cli. This has
| __nothing __to do with git.
| adriancooney wrote:
| I love this tool and use it everyday. Thank you Github and
| contributors.
| blntechie wrote:
| Good they have the Enterprise server support now. Time to try it
| now. I had to some hacks to use request-pull with the GitHub's
| process.
| janvdberg wrote:
| Is this coming full circle: Git -> GitHub -> GitHub CLI?
| nxpnsv wrote:
| Can we expect -> GitHubCLIHub which simplifies using the CLI
| with a website?
| dorianmariefr wrote:
| GitHubCLIHubCLIHub which simplifies using the GitHubCLIHub's
| CLI with a website
| DC-3 wrote:
| Reminds me of React -> React Native -> React Native Web.
| runarberg wrote:
| I guess GitHub CLI is kind of porcelain for the `git format-
| patch` and `git am`. Although I don't know of any git commands
| that will send or fetch the `.patch` files to the mailbox.
| u801e wrote:
| git send-email and git imap-send can send to a mailbox (the
| latter can be used to upload files to an IMAP folder). I
| don't know of a command that could download patches from a
| mailbox (though it would be nice if git provided one that
| would work with IMAP and/or NNTP).
| yakubin wrote:
| CLI or not, it's centralized/siloed all the same. I'm sticking
| to Git.
| londons_explore wrote:
| It would be really nice if the other features of github could
| get into the decentralized model of git... I could imagine
| issues and PR reviews/comments all being mini-commits to some
| kind of parallel metadata repo under the hood for example.
| trilinearnz wrote:
| 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!
| clon wrote:
| All of GH improvements have become irrelevant for me since they
| vanished one of our repos. No notification, no warning, no
| recourse. Just gonsky. It was just a simple library we wrote to
| talk to a public IP2Country REST service. Pushed to GitLab, end
| of.
| amiantos wrote:
| I find in situations like these that it's pretty unlikely that
| the person telling the story really has no idea why something
| bad happened to them.
| clon wrote:
| You are right. I have a hunch. In the local repo there is a
| file that was was probably produced by running wget
| github.com im the repo directory. Unsure what it was meant to
| achieve, but accidentally pushed, it may have flagged the
| repo down somehow. Maybe the HTML contained some secret
| token?
|
| Still, the main issue was the process how they handled it.
| Your build breaks. This is how we found out.
| martinwoodward wrote:
| Martin from GitHub here - love to understand what happened if
| you have the time to point me at more details. DM's open
| (martinwoodward on twitter and martinwoodward at github.com on
| email)
| clon wrote:
| I will send the repo URL in a few hours. Thanks for following
| up.
| sigwinch28 wrote:
| This is part of the problem.
|
| No recourse for such decisions unless you make a stink about
| it on an orange website or get enough likes on the website
| with the blue bird logo.
| whymauri wrote:
| Do you know whether the poster with a GitHub issue ever
| bothered reaching out to Enterprise support?
| bananabreakfast wrote:
| Probably wasn't a decision. And if it was, I'm sure it's
| much more complicated than OP is letting on.
| sigwinch28 wrote:
| Even an automated decision is a decision, because someone
| decided that's how the system should operate. Perhaps it
| was a bug?
|
| Furthermore, no: GitHub has a history of being bad at
| this kind of thing:
|
| https://news.ycombinator.com/item?id=22593595
|
| From the linked article: "A week after I've opened the
| support ticket, GitHub has finally replied. Suspiciously,
| this happened right after someone important has posted a
| link to this article on Hacker News"
|
| https://news.ycombinator.com/item?id=22628961
|
| Top comment: GitHub CEO coming in and apologising. From
| the linked tweet: "You sited US trade sanctions and sent
| me a non-descriptive email with no remediation
| information".
| duhi88 wrote:
| k.
|
| Clearly not that irrelevant if you're in here commenting.
| clon wrote:
| Should qualify that. I never said it doesn't sadden me to
| miss out on cool things. But professionally they are indeed
| irrelevant.
| clon wrote:
| Cannot edit any more, but it is important to clear this up.
| Apparently the repo did not vanish, it was deleted by a member
| of the team, who decided to keep silent about it for some
| reason.
|
| Tip - there is a "deleted repos" section in GitHub UI where
| they will appear, apparently with an option to restore them.
|
| In short - all I said seems to have been nonsense. Apologies!
___________________________________________________________________
(page generated 2020-09-17 23:00 UTC)