Introducing split diffs(github.com)
github.com
Introducing split diffs
https://github.com/blog/1884-introducing-split-diffs
24 comments
You may also enjoy syntax highlighting on your diffs[1]
[1] Pull requests are welcome: https://github.com/danielribeiro/github-diff-highlight-exten...
[1] Pull requests are welcome: https://github.com/danielribeiro/github-diff-highlight-exten...
Already using it :) Thanks for a great tool!
That's a subjective thing. Personally I can't stand split view :)
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.
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.
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.
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.
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.
> 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 ;).
We'll get there ;).
You could just use magit, right?
I started implementing some of it into magit, but I could never get magit + ediff working in a way I liked more than just invoking ediff myself.
Knowing the thorougness of magit, there's probably a way to successfully do this with minimal customization.
Knowing the thorougness of magit, there's probably a way to successfully do this with minimal customization.
As a fossil[1] user, this is something[2] I've been enjoying for some time. Nice indeed.
[1] http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
[2] http://www.fossil-scm.org/index.html/info/214b1d0a37487c94d0...
[1] http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
[2] http://www.fossil-scm.org/index.html/info/214b1d0a37487c94d0...
I like that the example screenshot is apparently showing the pull request that adds the feature.
Bitbucket has had a(n honestly better) version of this functionality for a while. One of the few areas where they beat Github.
As for which is better... depends. That's why it's good to have both on a toggle like so.
As for which is better... depends. That's why it's good to have both on a toggle like so.
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.
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]
[1] https://bitbucket.org/site/master/issue/2874/ability-to-sear...
[1] https://bitbucket.org/site/master/issue/2874/ability-to-sear...
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.
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.
Finally. Took them long enough. The unified view was always confusing.
I always saw the unified diff view as a bit of a holdover from the terminal.
Sure, diff works great if all you have is a VT220 ...
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!
Great comment in the example:
# Everything here is terribleI 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.
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.
I mentioned it above, but we're working on that. No idea when it'll happen as it's a bit more involved than that, but it will eventually.
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).
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).
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.
When viewing diffs in split view, they should remove the +/- indicators for additions/removals. The red/green highlight is enough.
(And for obj-c developers, it's annoying to see lines begin with `++ (void)...` or similar.)
(And for obj-c developers, it's annoying to see lines begin with `++ (void)...` or similar.)
> The red/green highlight is enough.
For people who can see red and green.
For people who can see red and green.
Indeed, there are many who can't distinguish these colors easily, especially males (~5%).
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
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
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.
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
It is more like 10% (depending on the source, e.g. wikipedia provides 8% for males)
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.
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.
Or be able to tell left from right.
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.
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.
Dear god finally.
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.)
You can by adding .patch to the end of a commit URL. For example:
https://github.com/andyhmltn/cherry-js/commit/3be55a2d6dab8e...
https://github.com/andyhmltn/cherry-js/commit/3be55a2d6dab8e...
On a local copy, with bash, use vim <( git diff )
then :sp (split)
This is great!
There is a small issue. When I resize my browser I get an unnecessary horizontal scroll bar. Im in latest stable Chrome on Mac
There is a small issue. When I resize my browser I get an unnecessary horizontal scroll bar. Im in latest stable Chrome on Mac
I can't believe Github hasn't had this until now. Gitlab by comparison has had split diff view for a long time.
The page width awkwardly jumps when toggling between unified and split diff. Is this a glitch, or intentional?
It's intentional. There's no way they can fit it side-by-side at the regular width (or it would be unreadable).
I actually like it. Finally a flexible layout that utilizes my screen estate.
All we need is comments on ?w=1 mode, and Github will be truly complete.
Awesome, that's definitely a feature I was hoping for :)
My screen is wider than it is tall. This is perfect.
[0]: http://phabricator.org/