From owner-svn-src-stable@FreeBSD.ORG Mon Feb 23 17:36:07 2015 Return-Path: Delivered-To: svn-src-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B740B9E6; Mon, 23 Feb 2015 17:36:07 +0000 (UTC) Received: from aslan.scsiguy.com (mail.scsiguy.com [70.89.174.89]) (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 8C81B312; Mon, 23 Feb 2015 17:36:06 +0000 (UTC) Received: from youathao-dell.sldomain.com (slboulder.spectralogic.com [192.30.190.3] (may be forged)) (authenticated bits=0) by aslan.scsiguy.com (8.14.9/8.14.9) with ESMTP id t1NHa5Uo065714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2015 10:36:06 -0700 (MST) (envelope-from gibbs@scsiguy.com) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: svn commit: r278718 - in stable/9: etc/rc.d sbin share/man/man4 share/mk sys/modules/geom tools/build/mk tools/build/options From: "Justin T. Gibbs" In-Reply-To: <5328252.MWfFGgsrnY@ralph.baldwin.cx> Date: Mon, 23 Feb 2015 10:35:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201502132136.t1DLaHLi008470@svn.freebsd.org> <5328252.MWfFGgsrnY@ralph.baldwin.cx> To: John Baldwin X-Mailer: Apple Mail (2.2070.6) Cc: svn-src-stable@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, svn-src-stable-9@freebsd.org, Garrett Cooper X-BeenThere: svn-src-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for all the -stable branches of the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 17:36:07 -0000 On Feb 16, 2015, at 9:11 AM, John Baldwin wrote: >=20 =E2=80=A6 >=20 > On a more general note, if I'm merging a change with several followup = fixes, I=20 >=20 =E2=80=A6 > 2) I don't cut and paste all N logs verbatim. This tends to be very = hard to read. I used to feel this way too until I started to see the many varied ways = that our downstream consumers import our revision history. For folks = who only import a single branch at a time or use a revision control = system that can=E2=80=99t easily pull in the original change text from = all integrated revisions, removing any content from the merge log is a = problem. Even when you do import all the data and have really good = tools for parsing it, it is nice when a naive search (a log of just the = current branch) is enough for you to find what you need. Merges should also be made easier, not harder. It is one thing to = require the change text to be edited to accurately reflect the content = of the merge (e.g. differences to maintain ABI compatibility, or the = exclusion of hunks that aren=E2=80=99t appropriate for the target of the = merge). But to require them to be summarized just because the reader = may have read the original change in another location just adds more = work, both for the person doing the merge and the future user of the = revision data. =E2=80=94 Justin=