
Introducing split diffs - dctrwatson
https://github.com/blog/1884-introducing-split-diffs
======
peter_l_downs
"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.

[0]: [http://phabricator.org/](http://phabricator.org/)

~~~
DanielRibeiro
You may also enjoy syntax highlighting on your diffs[1]

[1] Pull requests are welcome: [https://github.com/danielribeiro/github-diff-
highlight-exten...](https://github.com/danielribeiro/github-diff-highlight-
extension)

~~~
peter_l_downs
Already using it :) Thanks for a great tool!

------
epidemian
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](http://i.imgur.com/4Lcozgz.png). Not so good.
Contrast that with how IDEA renders the same diff:
[http://i.imgur.com/RGf8psr.png](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](http://i.imgur.com/AKNn1fW.png). It looks
very similar to the IDEA version:
[http://i.imgur.com/NpDsYBB.png](http://i.imgur.com/NpDsYBB.png). I wish GH
remembered the ?w=0 preference just as it remembers to use the split diff.

~~~
mdo
> 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.

------
codemac
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.

~~~
mdo
> 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 ;).

~~~
mackwic
So, you work at github now ? That explains a lot about the new bits of UI we
found here and there everyday.

What are you planning to do next ? Can't wait to get there.

~~~
mdo
Hah, been here for nearly two years now :). And no spoilers!

------
bch
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](http://www.fossil-
scm.org/index.html/doc/tip/www/index.wiki)

[2] [http://www.fossil-
scm.org/index.html/info/214b1d0a37487c94d0...](http://www.fossil-
scm.org/index.html/info/214b1d0a37487c94d0791f76a68198cea5f7885d)

------
rcthompson
I like that the example screenshot is apparently showing the pull request that
adds the feature.

------
thathonkey
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.

~~~
hrjet
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.

~~~
dserodio
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...](https://bitbucket.org/site/master/issue/2874/ability-to-search-
source-code-bb-39)

~~~
hrjet
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.

------
twodayslate
Finally. Took them long enough. The unified view was always confusing.

~~~
Scuds
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 ...

------
peterjmag
Great comment in the example:

    
    
        # Everything here is terrible

------
BrandonM
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.

~~~
mdo
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.

------
jtheory
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).

------
asnyder
Great stuff. If anyone's looking for a side by side diff paste bin, there's
[http://www.diffpaste.com/#/Diff/](http://www.diffpaste.com/#/Diff/), works
pretty well and lets you edit, iterate, and compare with previous versions.

------
joejohnson
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.)

~~~
aaronblohowiak
> The red/green highlight is enough.

For people who can see red and green.

~~~
jrapdx3
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](http://jfly.iam.u-tokyo.ac.jp/color/#assign)

~~~
mdo
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.

~~~
jrapdx3
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.

------
shuzchen
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.

------
pimlottc
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.

------
stefan_kendall3
Dear god finally.

------
pferde
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.)

~~~
andyhmltn
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/3be55a2d6dab8e9ab9f1573ea367fe2aa7797233.patch)

------
swehner
On a local copy, with bash, use vim <( git diff ) then :sp (split)

------
msoad
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

------
mrmondo
I can't believe Github hasn't had this until now. Gitlab by comparison has had
split diff view for a long time.

------
jefftchan
The page width awkwardly jumps when toggling between unified and split diff.
Is this a glitch, or intentional?

~~~
darkstar999
It's intentional. There's no way they can fit it side-by-side at the regular
width (or it would be unreadable).

------
jmorphy88
All we need is comments on ?w=1 mode, and Github will be truly complete.

------
wildpeaks
Awesome, that's definitely a feature I was hoping for :)

------
coherentpony
My screen is wider than it is tall. This is perfect.

