Unified diffs and GUI clients

Recently a user of MacHg asked how to display the differences in a file inside MacHg.

I personally have an opinion on this which differs somewhat from the established dogma. Thus I will outline my position here so I don’t have to elaborate it elsewhere, and hopefully it will make other GUI designers at least think about this issue.

The situation right now is that almost all GUI clients for Revision Control Systems (RCS’s) show differences “in application” through unified diffs. This is done because unified diffs are rather short and compact. But unified diffs don’t show all the surrounding code; and really in a large section of code with several changes, it is very difficult to immediately see what changes are occurring.

In fact, every single external GUI diffing program that I have seen has as default a side-by-side diff. (Some programs allow as an option, unified diffs, but it’s definitely something which is not the main thrust of the program.)

So, why does every single program that is dedicated to showing differences, display differences in a way different to that used inside almost all RCS GUI clients?

The reason is that most people sooner or later are forced into being able to recognize unified diffs. And after much exposure they begin to expect to see unified diffs, even though they are a very suboptimal way to view diffs.

Why do people get used to unified diffs? The reason is that since unified diffs are the raw format for diffs and are plain ASCII, they can be easily emailed around and inspected by people using tools which have nothing to do with diffing (eg email clients, text editors, displaying text on a web page, etc). In fact in some lists, sending unified diffs is the default way to exchange information, since in email ASCII is the lowest common denominator. (For instance, the mercurial development mailing list uses unified diffs as an interchange means of publicly discussing proposed changes.)

Of course, email is a very convenient interchange system, so developers are reading these unified diffs all day. Thus when some developer goes to create an RCS GUI client, they naturally put in the stuff they are working with all day, eg unified diffs.

But let’s take a look at what happens here in a screen shot from another RCS GUI client. (Note: I am not singling out this client amongst others, since many other clients do exactly the same thing.) However, of the overall window size (892 pixels x 689 pixels) the part which shows this unified diff is quite small (624 pixels x 192 pixels). Thus, just 19.5% of the window size is dedicated to showing the differences from one version of a file to the next in a semi-obfiscated patch interchange format.

I think its just sub-optimal.

(Of course for some die hard developers who eat, sleep, and breath unified diffs, maybe having some in program unified diff display is semi-convenient. However, to a large degree such people tend to use the command line in any case, so dedicating GUI features for them is futile.)

In this day and age of 32 inch LCD monitors, I think GUI RCS client programs need to live a little and somehow encourage the showing of diffs in the format that well… all dedicated GUI diffing programs use. Ie right now, use a very fast dedicated client or in-application code which shows the diff in a side-by-side format with full context in a large window.

(That said I have had more than a few requests for this feature in MacHg. And I try and do what users want… So maybe later I will have to toe the line and add these unified diffs into MacHG… But I am resisting for now…)

1 Comment »

  1. Thomas Traub Said,

    February 3, 2011 @ 4:59 pm

    Resist! Resist! There’re enough dedicated diff apps out there.

    And thanks for this great app.

Leave a Comment