suggestion for /usr/src/UPDATING

Evan Dower evantd at
Tue Aug 31 15:22:39 PDT 2004

This seems to me like a very good idea. Some people are very accustomed to 
the current defaults. They can just leave things alone. I personally have to 
think about which key to press, so I might change the keys to something more 
suitable to me. Perhaps an /etc/mergemaster.conf is in order or any other 
mechanism for allowing key (or more accurately character) customization. I 
see no reason not to let everybody win. In fact, I'd be perfectly happy if 
you couldn't change the default keys but could only add to them. That is, r 
and l would always work, but you could configure it so that other 
letters/keys would also have the same functions.
Just a thought and an opinion,
Evan Dower
Undergraduate, Computer Science
University of Washington
Public key:
Key fingerprint = D321 FA24 4BDA F82D 53A9  5B27 7D15 5A4F 033F 887D

>From: Charles Swiger <cswiger at>
>To: Brooks Davis <brooks at>
>CC: freebsd-current at
>Subject: Re: suggestion for /usr/src/UPDATING
>Date: Tue, 31 Aug 2004 17:08:55 -0400
>On Aug 31, 2004, at 4:31 PM, Brooks Davis wrote:
>>>I am content to let any interested committer make that decision, but I
>>>ask that  whoever first go through a trial mergemaster session using
>>>'1' & '2' as the keys.  'q' and 'e' are right there, and I found the
>>>improvement compared to using 'l' & 'r' immediately obvious and more
>>I agree the current default is confusing and counterintuitive, at least
>>at first.  That's not the point.  The point is that it's been that way
>>for ages and changing it would gratuitously screw all the users who have
>>adapted to it.  There's no reason why you couldn't preserve the old
>>behavior by default and in fact I'd request a back out of any commit
>>that didn't.  I don't opposes adding a second set of keys such as 1 and
>>2, just breaking the old behavior.
>I am more interested in permitting users to choose which keys they prefer 
>to use than I am in arguing what should be the default behavior of sdiff.
>It seems likely that if I'd commented out line 10 of my diff rather than 
>line 9, I'd be dodging brickbats from the other side, but what the hell, 
>the diff is the way it is because I wanted to test and see whether the 
>changes actually made a noticable difference in usability.
>I came to a conclusion, but the code I submitted is more friendly about 
>supporting individual opinions than the prior code, and your suggestion to 
>support multiple keys for choosing left and right also sounds like a good 
>idea-- probably more doable if one started with my changes.
>PS: I was going to ask, Brooks, whether you could describe a process you'd 
>tolerate for changing the default behavior of a program with unreasonable 
>freebsd-current at mailing list
>To unsubscribe, send any mail to "freebsd-current-unsubscribe at"

Don’t just search. Find. Check out the new MSN Search!

More information about the freebsd-current mailing list