GNU bug report logs - #20290
25.0.50; Use unified diff format by default, and recommend using it in reports and patches

Previous Next

Full log

Message #17 received at 20290 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 20290 <at> debbugs.gnu.org
Subject: Re: bug#20290: 25.0.50; Use unified diff format by default,
 and recommend using it in reports and patches
Date: Fri, 10 Apr 2015 15:26:38 +0300

On 04/10/2015 10:33 AM, Glenn Morris wrote:

> What's the reason for changing the long-standing default?

Unified diffs are considerably more popular. IIRC Stefan prefers them, 
and the vast majority of patches we've received lately (even though 
Emacs's documentation asks for the context format), were unified.

Which signals that users prefer, or at least are more used to, unified 
diffs. I've recently wanted to show off the "refinement" diff-mode 
feature to a colleague, and that stumbled on Emacs producing a context 
diff by default, so I had to go back to my machine, and look up which 
option to change (yes, I know there's a conversion command; haven't 
thought about that at the time).

>      * Use `diff -c' to make your diffs.  Diffs without context are hard
>       to install reliably.  More than that, they are hard to study; we
>       must always study a patch to decide whether we want to install it.

This is about the "normal" diff format, which, uh, nobody ever uses now?

>       Unidiff format is better than contextless diffs, but not as easy
>       to read as `-c' format.

And here I disagree: unified diffs are easier, because they clearly show 
you the changes. You don't need to compare the "before" and "after" in 
your head, to figure out what exactly changed. Maybe it can be a bit 
harder to read, but it's much easier to review.

Note that we already indirectly ask the users to send their patches in 
the unified format in CONTRIBUTE, because that's what 'git format-patch' 
will create.

> Also, one day is not long enough to allow people time to respond,
> for any Emacs issue.

Okay, let's wait until the next week.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.