Introducing split diffs

https://github.com/blog/1884-introducing-split-diffs

by dctrwatson • 12 years ago

280 51 12 years ago

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

gingerrr• 12 years ago

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!

Scuds• 12 years ago

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

peter_l_downs2• 12 years ago

"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/

the_mitsuhiko• 12 years ago

That's a subjective thing. Personally I can't stand split view :)

Terr_• 12 years ago

IMO one's better for comparing character changes, the other's better for comparing line changes.

DanielRibeiro• 12 years ago

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

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

peter_l_downs2• 12 years ago

Already using it :) Thanks for a great tool!

codemac2• 12 years ago

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.

mdo5• 12 years ago

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• 12 years ago

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.

lord_quas• 12 years ago

You could just use magit, right?

codemac2• 12 years ago

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.

jefftchan• 12 years ago

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

darkstar999• 12 years ago

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

the8472• 12 years ago

I actually like it. Finally a flexible layout that utilizes my screen estate.

msoad• 12 years ago

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

thathonkey• 12 years ago

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.

hrjet3• 12 years ago

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• 12 years ago

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

rcthompson• 12 years ago

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

wildpeaks• 12 years ago

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

bch• 12 years ago

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

asnyder• 12 years ago

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.

stefan_kendall3• 12 years ago

Dear god finally.

peterjmag• 12 years ago

Great comment in the example:

    # Everything here is terrible

jtheory• 12 years ago

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

shuzchen• 12 years ago

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.

joejohnson• 12 years ago

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• 12 years ago

The red/green highlight is enough.

For people who can see red and green.

shurcooL• 12 years ago

Or be able to tell left from right.

jrapdx33• 12 years ago

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

swehner• 12 years ago

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

jmorphy88• 12 years ago

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

pimlottc2• 12 years ago

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.

coherentpony• 12 years ago

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

BrandonM• 12 years ago

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.

mdo5• 12 years ago

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.

epidemian• 12 years ago

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.

mdo5• 12 years ago

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.

pferde• 12 years ago

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• 12 years ago

You can by adding .patch to the end of a commit URL. For example:

https://github.com/andyhmltn/cherry-js/commit/3be55a2d6dab8e...

mrmondo• 12 years ago

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

Introducing split diffs

Related Stories