From owner-freebsd-current@freebsd.org Tue Jul 24 02:26:13 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8D5A51034493 for ; Tue, 24 Jul 2018 02:26:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18B2079D7F for ; Tue, 24 Jul 2018 02:26:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: e7cc395f-8ee8-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e7cc395f-8ee8-11e8-aff6-0b9b8210da61; Tue, 24 Jul 2018 02:26:02 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w6O2Px5o014325; Mon, 23 Jul 2018 20:25:59 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1532399159.1344.211.camel@freebsd.org> Subject: Re: ntpd as ntpd user question From: Ian Lepore To: bob prohaska , "Herbert J. Skuhra" Cc: freebsd-current@freebsd.org Date: Mon, 23 Jul 2018 20:25:59 -0600 In-Reply-To: <20180724015428.GB47869@www.zefox.net> References: <5b90c49f-4616-9ef7-28a1-6445137245ef@nomadlogic.org> <1532191655.1344.80.camel@freebsd.org> <4b7acbd2-0230-345c-4370-24a72d0b492a@nomadlogic.org> <1532193285.1344.83.camel@freebsd.org> <20180721174722.GA40167@www.zefox.net> <1532196850.1344.87.camel@freebsd.org> <20180721220925.GA40238@www.zefox.net> <20180721234941.2ojf76kxxqfhnys7@mail.bsd4all.net> <20180723045552.GA44941@www.zefox.net> <87r2jtiw59.wl-herbert@gojira.at> <20180724015428.GB47869@www.zefox.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2018 02:26:13 -0000 On Mon, 2018-07-23 at 18:54 -0700, bob prohaska wrote: > On Mon, Jul 23, 2018 at 09:34:26PM +0200, Herbert J. Skuhra wrote: > > > > > > Yes, first you press m. Then you will see differences of installed > > file (left) and new file (right). Then you press either l or > > r: > > > > l | 1: choose left diff > > r | 2: choose right diff > > > > If the diff tries to remove/add to many lines you can: > > > > el: edit left diff > > er: edit right diff > > > > And if done you can view the merged file (v) before installing (i) > > it. > > > > I am sure, someone can explain it better! :) > > > Perhaps, but you've made the essential point. Your reply let me > understand that  > mergemaster does not really "master" the merge, it rather identifies > files needing  > to be merged and then starts sdiff to let me modify files. Never > having even looked  > at sdiff, the learning curve proved very steep. Too steep, in fact. > > I'm going to try a more incremental approach.  > > Thank you _very_ much! > > bob prohaska Your reaction to mergemaster is about the same as mine was when I first encountered it very long ago, and re-discovered when I tried it a couple years ago. It just seems like more trouble than it's worth, I can usually figure out what's broken and fix it by hand faster than messing with all the merge stuff. But, someone told me that if you give mergemaster the right flags it can potentially be intervention-free. Those apparently aren't the flag or two that're suggested at the bottom of UPDATING. So I didn't really dig into that any deeper, but I toss it out there in case someone can expand on it. It certainly makes some sense that it could be done intervention-free. When doing other diff-based merges (like 'svn update') you only have to intervene when there's an actual conflict between some local change you've made and the incoming changes. -- Ian