4 ms·

Hmm, as someone who spends most of their time on github looking at pull requests and issues, this seems a step backwards. Not a huge one, but it was nicer to h

Hmm, as someone who spends most of their time on github looking at pull requests and issues, this seems a step backwards. Not a huge one, but it was nicer to have my most frequent points of interaction at the top. I deal with the code itself in my local repo. I don't need to know how many commits/branches/tags/contributors there are -- that is the redundant info for me, and that should have been shoved to the side. If I'm using github's UI, it's because I'm managing a project. Might be nice to have a separate "management" interface you can opt into? tldr: They moved all the "extra" stuff to the side, while keeping the info directly related to the git repo in the center. But the whole point of using github is the value they add, not the core functionality that I can already get through my commandline!

simonz05 13y ago
I think their goal is the right; to reduce the vertical space usage at the top of the page before the "content". They did however remove some of the useful tabs and keep the least useful. Programming language stats and project description & project URL seems less important to me than the "code, issues, pull request etc" tabs.
- drone 13y ago
  Agreed. I've often presumed that stats (esp. language and commit counts, etc.) were part of the "social" aspect of GitHub, but not otherwise useful to me in any meaningful way most of the time. I think the sidebars are a step back for me. I preferred some useful content at the top, now having it on a sidebar just moves that content to the right side, away from my focus. One positive thing about the change is that "network" and "graphs" are now not co-mingled with main workflow items like Issues and Pull Requests.
DanielRibeiro 13y ago
My biggest gripe with it has been the lack of syntax highlighting for pull requests. Because of that I've been maintaining my personal fix for this: https://github.com/danielribeiro/github-diff-highlight https://github.com/danielribeiro/github-diff-highlight It would definitely be nice to see it supported natively by GitHub.
- zsombor 13y ago
  Does it also work when the syntax is outside of the diff context? I.e. think a html comment that started in an a prior insertion hunk? We had encountered a lot of edge cases whilst building the syntax highlighted diffs for https://www.tixef.com https://www.tixef.com It is a tricky domain, hats of to you for attempting it in JavaScript!
  - DanielRibeiro 13y ago
    Thanks! The highlihght is pretty much constrained to diff (on pull requests, commits and compares[1]), but it could work on any page. I've mentioned[2] how I used jquery-syntaxhighlighter to do it, which itself is a fork of Google's Prettify in order to do the heavy lifting of syntax discovery and actual highlight. [1] https://github.com/danielribeiro/github-diff-highlight/blob/master/src/header.js#L2 https://github.com/danielribeiro/github-diff-highlight/blob/... [2] https://github.com/danielribeiro/github-diff-highlight#hacking https://github.com/danielribeiro/github-diff-highlight#hacki...
  - eru 13y ago
    Just a naive question: Couldn't you highlight the two (or three) original sources, and then use that information to highlight the diff? Instead of trying to highlight the diff directly.
barumrho 13y ago
+1 Also, how often do contributors look at the source code on github? Contributors will most likely have the repo cloned on their machine. I think if management interface were to exist, it should default to Pull Requests or Issues, or some kind of dashboard that summarizes new activities in both.
- btown 13y ago
  I find the source code view is particularly useful as a dashboard because it gives modification times at a glance for each sub-directory, so as a non-maintainer you can tell whether there might be anything of interest to pull down (and possibly reconcile with local changes), without needing to go to that directory on your disk and do the fetch on the command line. So defaulting away from that isn't an obvious solution.
  - barumrho 13y ago
    I agree. I was talking about 'management interface' that shardling suggested. So, this would only kick in if you are a contributor of that project.
  - mcintyre1994 13y ago
    Would recent commits give that information more effectively than viewing the whole source?

simonz05 13y ago

I think their goal is the right; to reduce the vertical space usage at the top of the page before the "content". They did however remove some of the useful tabs and keep the least useful. Programming language stats and project description & project URL seems less important to me than the "code, issues, pull request etc" tabs.

drone 13y ago
Agreed. I've often presumed that stats (esp. language and commit counts, etc.) were part of the "social" aspect of GitHub, but not otherwise useful to me in any meaningful way most of the time. I think the sidebars are a step back for me. I preferred some useful content at the top, now having it on a sidebar just moves that content to the right side, away from my focus. One positive thing about the change is that "network" and "graphs" are now not co-mingled with main workflow items like Issues and Pull Requests.

DanielRibeiro 13y ago

My biggest gripe with it has been the lack of syntax highlighting for pull requests. Because of that I've been maintaining my personal fix for this: https://github.com/danielribeiro/github-diff-highlight https://github.com/danielribeiro/github-diff-highlight It would definitely be nice to see it supported natively by GitHub.

zsombor 13y ago
Does it also work when the syntax is outside of the diff context? I.e. think a html comment that started in an a prior insertion hunk? We had encountered a lot of edge cases whilst building the syntax highlighted diffs for https://www.tixef.com https://www.tixef.com It is a tricky domain, hats of to you for attempting it in JavaScript!
- DanielRibeiro 13y ago
  Thanks! The highlihght is pretty much constrained to diff (on pull requests, commits and compares[1]), but it could work on any page. I've mentioned[2] how I used jquery-syntaxhighlighter to do it, which itself is a fork of Google's Prettify in order to do the heavy lifting of syntax discovery and actual highlight. [1] https://github.com/danielribeiro/github-diff-highlight/blob/master/src/header.js#L2 https://github.com/danielribeiro/github-diff-highlight/blob/... [2] https://github.com/danielribeiro/github-diff-highlight#hacking https://github.com/danielribeiro/github-diff-highlight#hacki...
- eru 13y ago
  Just a naive question: Couldn't you highlight the two (or three) original sources, and then use that information to highlight the diff? Instead of trying to highlight the diff directly.

barumrho 13y ago

+1 Also, how often do contributors look at the source code on github? Contributors will most likely have the repo cloned on their machine. I think if management interface were to exist, it should default to Pull Requests or Issues, or some kind of dashboard that summarizes new activities in both.

btown 13y ago
I find the source code view is particularly useful as a dashboard because it gives modification times at a glance for each sub-directory, so as a non-maintainer you can tell whether there might be anything of interest to pull down (and possibly reconcile with local changes), without needing to go to that directory on your disk and do the fetch on the command line. So defaulting away from that isn't an obvious solution.
- barumrho 13y ago
  I agree. I was talking about 'management interface' that shardling suggested. So, this would only kick in if you are a contributor of that project.
- mcintyre1994 13y ago
  Would recent commits give that information more effectively than viewing the whole source?