From owner-svn-ports-head@FreeBSD.ORG Mon Sep 1 15:14:15 2014 Return-Path: Delivered-To: svn-ports-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 72E9EC0F; Mon, 1 Sep 2014 15:14:15 +0000 (UTC) Received: from apnoea.adamw.org (apnoea.adamw.org [204.109.59.150]) (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 48EB818C5; Mon, 1 Sep 2014 15:14:14 +0000 (UTC) Received: from [192.168.192.25] (dhcp-108-170-169-12.cable.user.start.ca [108.170.169.12]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by apnoea.adamw.org (Postfix) with ESMTPSA id 5C4C2114029; Mon, 1 Sep 2014 11:14:12 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: svn commit: r366841 - head/lang/tcl86/files From: Adam Weinberger In-Reply-To: <54048A3B.4030001@marino.st> Date: Mon, 1 Sep 2014 11:14:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201409010731.s817Vrxf062753@svn.freebsd.org> <20140901074609.GA32100@FreeBSD.org> <65B530D9-4740-4A60-A2F5-40335A520C4E@adamw.org> <54048A3B.4030001@marino.st> To: marino@freebsd.org X-Mailer: Apple Mail (2.1878.6) Cc: svn-ports-head@freebsd.org, Alexey Dokuchaev , ports-committers@freebsd.org, svn-ports-all@freebsd.org, Pietro Cerutti X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 15:14:15 -0000 On 1 Sep, 2014, at 11:01, John Marino wrote: > On 9/1/2014 16:47, Adam Weinberger wrote: >> On 1 Sep, 2014, at 3:46, Alexey Dokuchaev wrote: >>> Since when did we abandon the practice of doing 'svn diff' before >>> commit? >>=20 >> Alexey, please direct your frustration elsewhere. Pietro fixed >> (hopefully) a problem that caused a lot of tcl-dependent ports to >> break. He should be commended, not sneered at. If you don=92t like = the >> way makepatch works, take it up with portmgr, not with the committers >> who use it. I know for a fact that portmgr is interested in extending >> makepatch to DTRT. >>=20 >> Besides, there are simply situations where makepatch is just not the >> tool to use. Sometimes I *have* to run diff(1) by hand. Sometimes I >> need to run "make patch=94 before I can edit the diff. Sometimes I=92ve= >> edited multiple files and I want to test one diff at a time. >> Sometimes a file needs to be touched by two different patches (I >> don=92t like it, but ten years ago it seems like people really did). >=20 >=20 > While I also pushed back against danfe@ on this post, it's obvious = that > makepatch was used. The commit didn't do anything except change the > timestamp. Oh! I had missed that part. I apologize.... I thought it was about = changing the header in a patch that was being updated. > Danfe *did* rework makepatch, I helped him, and it's stuck > in review. His proposed version would not have resulted in a commit > that just changed timestamps. It does solve this problem. >=20 >=20 >=20 >> If you REALLY want to solve that issue, make a change to >> src/gnu/usr.bin/diff so that it will take a flag to not put >> timestamps in there. >=20 >=20 > As I said, the issue has been solved, and the solution is good. = Nobody > dislikes the new changes internally*, but patch-naming has turned into = a > impasse. Can I please request a partial commit of it? Just the stuff that makes = makepatch only update files that were actually changed, and commit = headers without timestamps? Seriously, let the naming convention piece = go for now, it is blocking everything else. > * since today, antoine says he thinks -p option on diff is "ugly". = it's > a highly useful option so now we have yet another hurdle to jump. If > not for phabric we could have had this in ports weeks ago, but now are > stuck in an impasse (which I suspect was the outcome desired by the > people that wanted it reviewed in phabric tbh) antoine is a perfectionist, and that=92s exactly what portmgr needs to = be.=20 # Adam --=20 Adam Weinberger adamw@adamw.org http://www.adamw.org