from Hacker News

Things I would build if I worked at GitHub

by holic on 8/5/15, 6:34 PM with 143 comments

• by felixgallo on 8/5/15, 8:15 PM

  These are great, but they're bugfixes. You'd finish them in the first few months. Then what are you going to do? Stare at an aquarium all day? Here's what I would build if I worked at github:

  * Github CI - simple CI for every language, integrating with:

  * Github Artifacts - repository for versioned deployable build packages (binaries, tar.gz files, ios builds, android builds...), integrating with:

  * Github Deploy - deploy tooling for deploying runnable artifacts or artifact combinations to either your own infrastructure, or to aws/azure/google, or:

  * Github Cloud - instances/containers as a service

  and the 'fork' button would be a pulldown that would include the options 'fork', 'fork and test', 'fork, test and deploy'. Now that's a nice little 3-4 year career.

• by danielsamuels on 8/5/15, 8:44 PM

  I've gotta say, I strongly disagree with this:

  > GitHub already has a great code search

  At some point in the last year or so Github rolled out a new search engine which drastically reduced it's usefulness. Any moderately complex search query now has all of the modifiers and key bits stripped out making your search results unnecessarily cluttered and somewhat useless. I consider it to be one of the worst parts of the site these days.

• by Buetol on 8/5/15, 8:19 PM

  Just see the top requested features: https://github.com/isaacs/github/issues?q=is%3Aissue+is%3Aop...

  * Change the target branch of a pull request pull-requests

  * Delete / remove an issue completely.

  * Gist comments and mentions don't trigger notifications

  * Add HTTPS support to Github Pages

  * Add ability to follow organizations like a user

  * Insert automatically generated table of contents TOC on rendered markdown files like README.md.

  * pre { tab-size: 4 }

• by geofft on 8/5/15, 8:00 PM

  It seems like some of these (perhaps all of them other than fixing the "+1" problem) can be done via API clients instead of via GitHub itself implementing it. A third-party website can do wiki searches. A separate service can send you email notifications, and you can turn off built-in emails.

  Even the +1 thing might be solvable with a bot that edits each bug report to add a clickable +1 badge (a la the CI build-passing badges) at the top; all you need is to give the bot ownership of your repository. The badge can display the current +n count, and the service can give you a sorted list of open issues by +n. For bonus points, have the bot also harvest and remove comments that consist of just "+1" or ":+1".

  This is GitHub after all; why don't we build stuff ourselves instead of waiting for a centralized closed-source company to decide they care about our features?

• by Jemaclus on 8/6/15, 4:10 PM

  The only thing I really, really want is paginated diffs for pull requests. C'mon. If I have 300 files, don't show me the first 15 and then say "well, this is too big, you'll just have to imagine what the rest of the diff looks like." Does Google return the first page and then say "the rest of the internet isn't available to you because we don't want to paginate things"? No, of course not. Just freaking paginate long diffs.

  Gah.

• by fiatjaf on 8/5/15, 8:54 PM

  A better way to browse forks.

  If today you see that a major repository has a fork with a lot of commits, you cannot know without looking through THEM ALL if they are just typo fixes or if the fork is really changing/improving things over the main repo.

• by simonw on 8/6/15, 4:12 AM

  The biggest thing I want from GitHub is the ability to search commits. GitHub are pretty good at search (their issue search is fantastic, and their code search is decent enough) - but the data I most want to search are the commit messages in my repo.

  I understand this will be a huge amount of data (they must have hundreds of millions if not billions of commits by now). I'd be perfectly happy if this was only available for paid repositories.

  The ability to then further facet and filter searches by author, file, directory etc would be unbelievably useful.

• by andrewbinstock on 8/5/15, 10:30 PM

  By far the biggest thing I wish github would do is change the text entry beside the file names. Right now, it shows the comment of the last push of edits to that file. That's great for members of the project.

  However, for non-members it would be far more useful to know what the file is. Here, enabling a one-line description would be hugely helpful.

  Since GH knows if you're a member of the project it can show you the right text--description or latest update. And presumably, a button would allow you to see the other text if you needed it.

• by kzhahou on 8/5/15, 8:26 PM

  They'll need another $100 million to get these done!

  (Yes, by which I am saying their website has not improved much given their massive funding)

• by stevekemp on 8/6/15, 8:37 AM

  I see people here posting issues of their own, but I'm amazed nobody has yet mentioned the lack of IPv6.

  I've setup a few machines with IPv6-only network connections, and it makes pulling my dotfiles from github a pain since I need an IPv4-proxy/tunnel to access github.com

• by sytse on 8/5/15, 8:28 PM

  Great list, we're working on making something that makes +1's less noisey. If you want the possibility to contribute to the tools you use daily consider using our GitLab. It is open source and more than 800 people have contributed already.

• by foolfoolz on 8/5/15, 9:28 PM

  git hubs worst problem: FIXED WIDTH CODE READING

  code is read way more often than written. and on github website all you can do is read it. why the viewports don't take up the entire screen width i will never understand.

• by jarjoura on 8/5/15, 8:11 PM

  My biggest pet-peeve about GitHub is its issue tracker system. It's great for one-off issues or tracking a pull-request, but beyond that its design is super unwieldy. Such a missed opportunity to crush JIRA, et. al.

• by nickbauman on 8/5/15, 7:51 PM

  Absolutely fix the pull request interface. It currently reads like a ransom note. Go over to bitbucket.org and copy theirs. It's 100x better.

• by lhnz on 8/5/15, 8:01 PM

  Personally, I'd like a nice GUI to pick and squash commits with new commit messages against them on creating a pull request. I don't enjoy using the CLI for this, and it would be nice to thread thoughts on the solution into the commits themselves rather than explaining solely in the PR description.

• by hlfcoding on 8/6/15, 12:47 AM

  An unordered list of missing features from me:

  - No ability to store the tab size setting. While appending '?ts=2' to the url is ok, it's not convenient and usable on a daily basis. The same for omitting whitespace changes in a diff / pr ('?ws=1').

  - No ability to step through history on a single file while in blob view, or blame view. In blame view, the commit link goes to the commit, not the blame of the file at that commit.

  - Agree with OP that notifications need to be grouped / summarized better. Perhaps expandable summary items per repo per type. This is mostly useful for private, work-related repos. Pulse and notifications are basically the same thing.

  - Stars cannot be tagged. This makes managing hundreds of stars difficult. There's apps like Astral, but even those are lacking.

• by jasode on 8/5/15, 8:02 PM

  Those are interesting suggestions, but my guess is that they are probably focusing on features to make github more enterprise friendly. If a16z invests $100 million in github, it doesn't seem like streamlining emails will have the ROI that investors expect.

  Maybe github is focusing on creating a full software development lifecycle management (ALM) in the cloud. (Like Microsoft Team Foundation Server and JIRA.) A dashboard for sprints, defect fixes, issues tracking, etc. That's the type of "enterprisey" thing that attracts more business subscriptions. They use the storage of sourcecode repositories to open doors to other sw development related business.

  These are just my guesses. I haven't seen any explicit roadmap from github.

• by epberry on 8/5/15, 8:39 PM

  Wiki search is #1 on my wish list for Github. I see others talking about cloning the wiki repo locally and searching it but for big projects this would be the equivalent of downloading something like the Python docs and searching them. It could be done but it would be a massive pain in the ass.

  I have written most of the documentation for the project I contribute to the most and I organized the wiki like a two level tree where a top level page has links to category pages and each page on the wiki is linked to from one of those category pages. Then there are links interspersed among the pages like a normal wiki. This structure works okay but I know it can be better because sometimes I cannot even find information that I produced!

• by andrewchambers on 8/6/15, 4:30 AM

  One thing that has bitten me is the code review submitting each line of feedback instantly, before you have finished reviewing the whole pull request.

• by arikrak on 8/6/15, 3:06 AM

  I feel one could have more ambitious goals. E.g. Could Github build a powerful developers careers site based on all the data they have? Could they provide more tools to help people program? (Could they automatically create programs? https://news.ycombinator.com/item?id=9973088)

• by kranzky on 8/6/15, 12:23 AM

  Things I would build:

  * Push conflicted branches so developers in a distributed team can work together to resolve conflicts.

  * A git-powered version of Rake, which runs only those tests that need to be run based on the git history since the last run.

  * A tool to identify what code changes caused a particular test to fail, based on the above.

  * Language syntax detection for smarter diffs, improving the display when blocks of code are moved around or indented/outdented.

  * Language linters built in, to detect when a change is introducing a syntax error. Same for coding style.

  I'd also move the "Close Pull Request" button a little farther away from the "Comment" button, and make it possible to add comments to a diff when you've hidden whitespace differences (with `&w=1`... I'd also make it a bit more obvious that you could do that).

• by masklinn on 8/6/15, 10:05 AM

  > The suggested alternative is to "Subscribe" to an issue for updates, which is what I've started doing to issues that I want to show my support for. My support, however, isn't visible to anyone else.

  Though following the resolution of an issue usually means I'd like for it to be resolved, the converse isn't true: I've hit thousands of issues over the years but most of the time I've been able to work around them and haven't hit it since, resolving the issue would be nice for people coming after me, but I don't really care to be spammed by its status updates.

  So yes, "subscribe" could count as a +1, but no "subscribe" should not be the only way to "+1" an issue.

• by kevinSuttle on 8/5/15, 8:12 PM

  I started this as well: https://github.com/kevinSuttle/github/issues (not the same Kevin as link author)

• by TheRealWatson on 8/5/15, 10:54 PM

  I always wished GitHub had a chat room per repo. Fully integrated with github features, like mentions, issues, pull requests. Maybe even hubot builtin.

• by davidcelis on 8/5/15, 9:33 PM

  For the "voting on issues" feature I'd really just love to see them clone Slack's recent "Emoji Reactions" feature.

• by bronson on 8/6/15, 6:43 AM

  How about making pull requests less centralized? Right now, if I file a PR, only the project admins or I can modify/rebase it. I'd like to give other (non-admin) collaborators permission to work on it too.

  Or, maybe it could use a forking model? Let anyone fork their own PR from mine, make those forks prominently visible in my base PR, and make it easy for me to merge their edits back in.

• by eam on 8/5/15, 8:48 PM

  Getting notifications/emails when a new release is released of a repo I'm watching or have starred would be awesome!

• by web007 on 8/5/15, 8:01 PM

  I reported this a while back, so it's in their backlog somewhere but obviously not super-important:

  I'd like to see an option to turn off fork notifications for org projects without turning off all org notifications. As-is, I get an email for every dev forking every project, sometimes more than once due to lack of git knowledge.

• by jpdlla on 8/5/15, 8:43 PM

  * Search code in a branch other than master. * Advanced code search inside a repo(match searches with symbols, etc.)

• by rocky1138 on 8/5/15, 8:41 PM

  Search can be easily worked around by using Google with the site: parameter, e.g., search on Google with this query:

  wireless site:https://github.com/esp8266/esp8266-wiki/wiki

• by adamnemecek on 8/6/15, 1:01 AM

  I would make the search results deduplicated. It happens to me a lot that I search for something and the first 10 pages of search results are from the same 5 projects, but from different locations within the single projects. I usually lose patience sometime around page 5.

• by electic on 8/5/15, 9:12 PM

  I would also like to see GitHub Chat. Complete Slack killer with the same heart and spirit of Atom.

• by mpdehaan2 on 8/5/15, 8:50 PM

  This is a really good list.

  As for sorting things by file, here's a pretty cool project to do that using GitHub API - https://github.com/sivel/pr-triage

• by TheRealWatson on 8/5/15, 11:04 PM

  It's very common, at least on my team, to create pull requests for the wrong target branch. I don't see why GitHub doesn't allow you to fix it before any comments are posted. This would save some useful time.

• by thinkbohemian on 8/5/15, 8:16 PM

  Better filters for emails. Would love to subscribe to only new issues on a repo or random issues on a repo. Basically http://codetriage.com

• by pietherr on 8/6/15, 8:37 AM

  Things @teabass would build if he quit GitHub: https://libraries.io

  Really useful to get updates on new releases of libraries you use.

• by tacone on 8/5/15, 9:40 PM

  To be frank, it is pretty much ok for the +1 to be annoying: it's often what they are meant to. Thus, if a vote button were to be implemented, it would not be used all the time.

• by fogonthedowns on 8/5/15, 9:58 PM

  I would really like to have the ability to Edit commit messages using the web interface. I'm often stuck with a poorly crafted message and an edit function would help that.

• by jkmcf on 8/5/15, 10:09 PM

  Better blame history navigation, functionally the same as how Textmate does it.

  1. git blame file 2. click on a hash for the change 3. show the file for that change

  Right now, (3) shows you the diff for the hash

• by qntmfred on 8/5/15, 8:17 PM

  https://github.com/isaacs/github has a ton of these missing features

• by choward on 8/6/15, 12:10 AM

  > These are great, but they're bugfixes.

  I agree with every you said but that first sentence. How are these bugs? They are features that never existed.

• by artur_roszczyk on 8/5/15, 8:00 PM

  +1

  I would also implement a button for reverting pull requests already merged in master. Reverting merges may be not trivial for less experienced users

• by Linell on 8/5/15, 7:52 PM

  I'd also love for commit messages to be parsed as markdown. I can't really think of a downside to it.

• by tsuresh on 8/5/15, 8:04 PM

  GitHub wiki is a repo and can be cloned locally. Searching through a local files is trivial.

• by sandGorgon on 8/5/15, 8:04 PM

  I would build a Slack alternative + Jira alternative that is deeply integrated into Github.

  QED.

• by ocdtrekkie on 8/5/15, 9:59 PM

  I'd kill for merge conflict resolution in the web UI.

• by fred2133 on 8/6/15, 8:55 AM

  Github Firehose if it was me.

  Something to build tools on top of.

• by jafingi on 8/6/15, 9:12 AM

  +1

  ;-)

• by brobdingnagian on 8/5/15, 8:12 PM

  The ability to search your own gists!

• by OedipusRex on 8/5/15, 7:51 PM

  I hope all of his post on this blog are like this one (https://kevin.is/committed-to-github/, Kevin is committed to GitHub)