It got a bit better when they added the ability to expand context, but that always felt like a way to avoid committing to split diffs all the way. Glad they're here!
"Split diff" is absolutely essential to performing code review; after having used it in Phabricator [0] I was severely disappointed whenever I had to use Github's vertical view. Great to see Github finally play catchup, congrats to the team that shipped it.
I almost sent an email at work in all caps rejoicing this. Redid the casing, then sent it. Very pleased to see this.
I had implemented my own git fetch pr -> emacs ediff -> commints in org file -> add comments to github flow due to how horrible the unified view was for long/large code reviews.
If they can unfuck the "so-and-so has commented on an old commit" thing hiding valuable conversation, we start to get into a real code review tool.
Bitbucket has been advancing in many areas. Did a recent evaluation of Github and Bitbucket for an upcoming project.
Github's issue management is optimal for small projects. But Bitbucket shines at issue management for large projects: priorities, voting, watching, components, issue workflow.
Bitbucket also has a responsive and fluid design that utilizes screen real-estate better.
All-in-all, I am seriously considering Bitbucket for larger projects.
Bitbucket's lack of a code search feature is a serious disadvantage, specially for large organizations. The enhancement request has turned into a ranting thread[1]
Ah, thanks for the link. Hadn't checked for code-searchability.
The nice thing is bitbucket has an issue tracker for the site. I am sure Github would have a similar list of pet peeves if it had a way to publicly track feature requests.
Great stuff. If anyone's looking for a side by side diff paste bin, there's http://www.diffpaste.com/#/Diff/, works pretty well and lets you edit, iterate, and compare with previous versions.
That's great -- split diffs are a much more intuitive way to review most kinds of changes.
The next step will be to have smart split scrolling, so you don't have to leave gaping holes on one side or the other to accommodate additions/removals of large chunks of code (all the not-really-there blank lines can make it harder to grasp the flow).
Bitbucket has had this for a long time time now (years I think). I've been waiting for (and complaining about lack of) side-by-side diffs on github for some time now.
Whoa, I never thought about that. The colorblindness thing is exactly why we haven't tried to remove the +s and -s, but if there are indeed colors that we could attempt to use, that'd be awesome.
Doing both things allows the maximum number of users to benefit. I'm pretty sure that's what you were getting at.
The diff convention of marking inserted and deleted lines by + and - provides a "channel" of info showing text comparisons. If the + lines were also blue-green and the - lines also red-violet then there's two channels conveying the same information.
Using colors or not, we'd definitely keep the +/- markers.
The highlighting methods are distinct, but line information is the same. The +/- notation will still be useful on a monochrome monitor or printed page. On a spiffy new 2500x1600 display, I'd personally prefer the color output to quickly find what's changed.
Wow, thanks for the handy link! I have always wanted a good explanation to provide for quick posts. I created a short URL for easy reference: tinyurl.com/colorassign
Certainly depends on the source. But I believe you are about right. I wrongly trusted memory for the stat. The figure I used applies to a subset, green perception impaired males, which is around 5-6%, depending on level of impairment considered.
As you note, including the red perception impaired adds ~2% of males. And about 0.5% of females are also color-vision impaired. Overall it is around 9% of the US population.
The prevalence of color-blindness varies by racial/ethnic criteria, and between groups male/female ratio varies quite a bit. Color vision is a very fascinating subject.
When I read "split diffs" I think about splitting up a diff into different two or more diffs (like in "git add -p"). "Side by side" or perhaps "parallel" view would be more descriptive here. Still, a very useful and overdue feature.
I would prefer this feature on a file-by-file basis. I usually prefer the unified diff, but for some changes, the diff is so bad that it becomes useless; that's where I would use a split diff.
Another diff-related improvement I'd love to see is useful whitespace removal. I know you can do it with a URL flag (`&w=1`), but then you can't make comments, meaning you have to switch back and forth to use it.
While this is a very welcomed change, i feel the split diff view could do a much better job on some cases.
For instance, this is how GitHub renders a commit that adds a wrapper HTML element (and indents all its contents) and changes a class name: http://i.imgur.com/4Lcozgz.png. Not so good. Contrast that with how IDEA renders the same diff: http://i.imgur.com/RGf8psr.png. It makes it obvious where the wrapper tags where added, and which class name changed (which is completely lost within the green glob of the GH diff).
Now, the whitespace-agnostic view on GH (adding ?w=0 to the diff URL) is much better: http://i.imgur.com/AKNn1fW.png. It looks very similar to the IDEA version: http://i.imgur.com/NpDsYBB.png. I wish GH remembered the ?w=0 preference just as it remembers to use the split diff.
> I wish GH remembered the ?w=0 preference just as it remembers to use the split diff.
Me too! I'm working on that, but it's a bit tough as it changes the order of the lines that are rendered in the browser. Thus, code comments would kind of be borked.
Bottom line, lots to rewrite before we can do just that, but we are 100% aware of it.
All that's needed is an easily reachable way to fetch raw diff. You can then view it locally in any way you want. (Maybe github already does this, I don't really use the site.)
52 comments
[ 0.20 ms ] story [ 103 ms ] thread[0]: http://phabricator.org/
[1] Pull requests are welcome: https://github.com/danielribeiro/github-diff-highlight-exten...
I had implemented my own git fetch pr -> emacs ediff -> commints in org file -> add comments to github flow due to how horrible the unified view was for long/large code reviews.
If they can unfuck the "so-and-so has commented on an old commit" thing hiding valuable conversation, we start to get into a real code review tool.
We'll get there ;).
What are you planning to do next ? Can't wait to get there.
Knowing the thorougness of magit, there's probably a way to successfully do this with minimal customization.
There is a small issue. When I resize my browser I get an unnecessary horizontal scroll bar. Im in latest stable Chrome on Mac
As for which is better... depends. That's why it's good to have both on a toggle like so.
Github's issue management is optimal for small projects. But Bitbucket shines at issue management for large projects: priorities, voting, watching, components, issue workflow.
Bitbucket also has a responsive and fluid design that utilizes screen real-estate better.
All-in-all, I am seriously considering Bitbucket for larger projects.
[1] https://bitbucket.org/site/master/issue/2874/ability-to-sear...
The nice thing is bitbucket has an issue tracker for the site. I am sure Github would have a similar list of pet peeves if it had a way to publicly track feature requests.
[1] http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
[2] http://www.fossil-scm.org/index.html/info/214b1d0a37487c94d0...
The next step will be to have smart split scrolling, so you don't have to leave gaping holes on one side or the other to accommodate additions/removals of large chunks of code (all the not-really-there blank lines can make it harder to grasp the flow).
(And for obj-c developers, it's annoying to see lines begin with `++ (void)...` or similar.)
For people who can see red and green.
Better off using reddish-purple and bluish-green, and also different fonts to indicate changes. That would be a kindness.
See http://jfly.iam.u-tokyo.ac.jp/color/#assign
The diff convention of marking inserted and deleted lines by + and - provides a "channel" of info showing text comparisons. If the + lines were also blue-green and the - lines also red-violet then there's two channels conveying the same information.
Using colors or not, we'd definitely keep the +/- markers.
The highlighting methods are distinct, but line information is the same. The +/- notation will still be useful on a monochrome monitor or printed page. On a spiffy new 2500x1600 display, I'd personally prefer the color output to quickly find what's changed.
As you note, including the red perception impaired adds ~2% of males. And about 0.5% of females are also color-vision impaired. Overall it is around 9% of the US population.
The prevalence of color-blindness varies by racial/ethnic criteria, and between groups male/female ratio varies quite a bit. Color vision is a very fascinating subject.
Another diff-related improvement I'd love to see is useful whitespace removal. I know you can do it with a URL flag (`&w=1`), but then you can't make comments, meaning you have to switch back and forth to use it.
For instance, this is how GitHub renders a commit that adds a wrapper HTML element (and indents all its contents) and changes a class name: http://i.imgur.com/4Lcozgz.png. Not so good. Contrast that with how IDEA renders the same diff: http://i.imgur.com/RGf8psr.png. It makes it obvious where the wrapper tags where added, and which class name changed (which is completely lost within the green glob of the GH diff).
Now, the whitespace-agnostic view on GH (adding ?w=0 to the diff URL) is much better: http://i.imgur.com/AKNn1fW.png. It looks very similar to the IDEA version: http://i.imgur.com/NpDsYBB.png. I wish GH remembered the ?w=0 preference just as it remembers to use the split diff.
Me too! I'm working on that, but it's a bit tough as it changes the order of the lines that are rendered in the browser. Thus, code comments would kind of be borked.
Bottom line, lots to rewrite before we can do just that, but we are 100% aware of it.
https://github.com/andyhmltn/cherry-js/commit/3be55a2d6dab8e...