I'd kill for merge conflict resolution in the web UI.
Things I would build if I worked at GitHub
71–80 of 145 posts
Re: Things I would build if I worked at GitHub
#72A 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.
This. The amount of time I have wasted looking in forks is staggering.
100% agree. I wish there was some way to also promote a fork, other than changing the readme to point to the new fork, which also means mucking up the history of the project.
Re: Things I would build if I worked at GitHub
#73git 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.
Yeah, that's a puzzling one. I've been using a browser script for a long time now to make the code view full width.
I don't use it often, but I have a Javascript bookmark [0] that I use in Chrome when the 100-character width is excessively abused. Over time, I found I dislike using it enough that I now try to limit my lines to 100 characters in my editor, so that my github diff presentation is easier to read.
I'm sure there's an easier way to do this. I'm pretty certain I cribbed the method of setting a style from a StackOverflow article or other thing found online, but that was three years ago so I do not recall where it was. (Sorry.) I think all I did was poke around the Chrome debugger until I found the styles I needed.
Re: Things I would build if I worked at GitHub
#74Earlier quoted context omitted.
>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? Why would I build something for a centralized closed-source company?
Because then the only thing you're relying on the centralized closed-source company for is actual git hosting. This is a boring problem that dozens of other services solve well, and thousands of other services (like S3) solve poorly in a pinch. If you can migrate the interesting part of GitHub -- issue tracking, PRs, wikis, etc. -- to another provider, and GitHub just holds your data, then you're no longer locked in.…
Migrating issue tracking and other stuff out of Github seems like a good idea if you want to reduce dependency, building a bot on top of Github issues - what you implied in your parent post - not so much.
Re: Things I would build if I worked at GitHub
#75Better 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
Re: Things I would build if I worked at GitHub
#76By 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.
Re: Things I would build if I worked at GitHub
#77These 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 - d…
Of all the things I wish Github had, a mailing list service would be really amazing, and the kind of thing that wouldn't be done in the first few months. Sourceforge offers atrocious mailman-based email, larger foss projects on github suffer :(
What appeals to you about mailing lists?
If it's reporting issues, discussion solutions, and reviewing patches, there are Issues and Pull Requests.
If it's for general discussions about the "future of the project" or bigger-picture topics, I'd use Discourse. It's a really nice way to organize discussions that are one step removed from code-related issues.
If it's for things where you need quick or real time feedback, there's IRC, Gitter, and Slack, all great options for messaging/chat.
Re: Things I would build if I worked at GitHub
#78A 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.
One way that has served me as being a pretty good metric of what's what when it comes to forks looking at the number of stars the parent and child repos have. If a fork has started to usurp it's parent, it generally has a fair deal of its own stars.
Re: Things I would build if I worked at GitHub
#79I always wished GitHub had a chat room per repo. Fully integrated with github features, like mentions, issues, pull requests. Maybe even hubot builtin.
Re: Things I would build if I worked at GitHub
#80By 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…
If you don't know where to look it can take a surprisingly long time to find things like: https://github.com/torvalds/linux/blob/master/Documentation/.... It is obvious once you know, but unless you know are in the habit of checking all the 'likely places' such a doc would be you are going to be lost. While one could allow annotations on top of files in github it would completely fragment real and important documentation efforts and leave information scattered in 10 different locations that no one could pull back together.