Git is a handy tool that many of us are using for more than just software development. Having a cloud-based upstream repository is also surprisingly useful, but until now using GitHub — the most common upstream server — meant firing up a web browser, at least for certain tasks. Now GitHub is releasing a beta version of command-line tools made to manipulate your GitHub repos.
The tools are early release so they mostly focus on issues and pull requests. Of course, git itself will do the normal things like clone and checkout — you’ve always been able to do that on the command line. The example given in the announcement blog post lists all issues with a help wanted label:
gh issue list --label "help wanted"
We noticed that asking to view the issue, while done on the command line, will still open a browser. The tools are still a little early, so this is an excellent time to let the developers know what you’d like or otherwise influence the project.
We were a little surprised it wouldn’t just consume git, so that you’d use the same commands for everything and it would just pass pre-formed commands to git. Of course, that would be pretty easy to write as a shell script wrapper if you were interested in such a thing.
You’d be forgiven for only thinking of git as a way to manage source code revisions, but it’s actually capable of all sorts of interesting tricks.
Like fossil, git should integrate issues, PR discussion, forum and all the “good stuff” into the normal local tool to make real peer based development possible. The need for a central hub is a good business model because each git repository clone lacks the most important pieces for the team workflow. So you get a locked in syndrome. Pulling only the access to issues to the commandline without being able to clone issues and all that stuff locally for completely working peer based is not a solution.
TAKE BACK CONTROL!
Mail [Linus T.] to finish git by making github/gitlab/… obsolete!
Yes. It feels like the “wiki” section on github can be easily replaced by subdirectory/submodule with bunch of markdowns. Other features might work in similar manner.
Github/gitlab makes the code available to people outside of core developers circles. Anyone can download a copy of the code (zip of a snapshot of the directory directly from web) *without* some obscured commands, installed specialized software/environments or having to sign up etc. To small developers, it also act as a hosting service or distribution.
What is “good” for the developers isn’t necessarily good for others.
Spot on
> completely working peer based
seems impossible on this Internet.
When I file a bug to some random person’s project, how do I get everyone to pull it from me into their local repo’s bug tracking system? Where do I push it? At least sourcehut.org hosts mailing lists. Yes, that is just another centralized thing, which sometimes is what we need.
The shell wrapper option sounds better than installing this golang garbage onto my system.
it looks like it is just the front page that is behind a login wall you can still go to existing projects
Didn’t they do this with “hub” already?
Seems like they consider hub unofficial, and gh the ‘official’ CLI. From the readme at https://github.com/cli/cli
Comparison with hub
For many years, hub was the unofficial GitHub CLI tool. gh is a new project for us to explore what an official GitHub CLI tool can look like with a fundamentally different design. While both tools bring GitHub to the terminal, hub behaves as a proxy to git and gh is a standalone tool.
Just fork Git to add the nice features that Fossil has.
The “decentralized” feature claimed from day 1 was just propaganda.
https://github.com/github/hub might be the wrapper you were looking for.