From owner-dev-commits-src-main@freebsd.org Wed Dec 30 21:31:18 2020 Return-Path: Delivered-To: dev-commits-src-main@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 902E04CF8D0; Wed, 30 Dec 2020 21:31:18 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5kxL2LPRz4hRL; Wed, 30 Dec 2020 21:31:17 +0000 (UTC) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 0BULVEfr083619; Wed, 30 Dec 2020 13:31:14 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 0BULVETD083618; Wed, 30 Dec 2020 13:31:14 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <202012302131.0BULVETD083618@gndrsh.dnsmgr.net> Subject: Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL In-Reply-To: To: Warner Losh Date: Wed, 30 Dec 2020 13:31:14 -0800 (PST) CC: "Rodney W. Grimes" , Glen Barber , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4D5kxL2LPRz4hRL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Commit messages for the main branch of the src repository." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Dec 2020 21:31:18 -0000 > On Wed, Dec 30, 2020 at 5:13 AM Rodney W. Grimes > wrote: > > > > On Tue, Dec 29, 2020 at 04:18:07PM -0800, Rodney W. Grimes wrote: > > > > > The branch main has been updated by gjb: > > > > > > > > > > URL: > > https://cgit.FreeBSD.org/src/commit/?id=70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > > > > > commit 70e64ba4494190e64ab8faa04d744182d420c275 > > > > > Author: Glen Barber > > > > > AuthorDate: 2020-12-29 14:34:05 +0000 > > > > > Commit: Glen Barber > > > > > CommitDate: 2020-12-29 14:40:28 +0000 > > > > > > > > > > release.sh: Update GITROOT URL > > > > > > > > > > Hard-code the GITROOT for the ports tree to use cgit-beta > > > > > until the ports repository is converted. > > > > > > > > > > While here, remove $FreeBSD$ RCS IDs. > > > > > > > > So how do I know what version of some file I am looking at > > > > once it has been dis-associated from a git clone? > > > > > > > > > > You can't. Git does not expand the tags. > > > > And no new mechanism in place to replace it? So, we have > > no versioning of files in the final product any more? > > > > No. We will not. That I take a very hard line against, that is IMHO a very big mistake. > > Sad, very very sad :-(. This may cause some down streams, > > other than me, some very serious heart ache. > > > > Git provides tools to reduce that heart ache. You can get the same info, > but using different means using git's tools should you need to. See other mail to Ryan, those tools well not help with the issues of locally modified files and being able to figure out what base they started with. > > > > > > Is there some new mechanism that can give me the cadence of > > > > say, /etc/pkg/FreeBSD.conf once its FreBSD ID is riped out? > > > > > > > > Also if $FreeBSD$ needs to be removed, can we please just do > > > > it in one massive tree wide commit rather than have this > > > > random piece wise needless noise in 1000's of commits? > > > > > > > > > > Please, no. There is no benefit to prune these in one fell swoop as > > > opposed to, for example, bumping Copyright dates. > > > > Well have to disagree on that. > > > > a) If it is removed in one fell swoop it can also probably > > be undone in one fell swoop too. > > > > It won't ever be undone, so this is irrelevant. I would be careful with any claim of never. > > > > b) It concentrates the change in 1 commit that does NOT > > ever need to be MFC'ed. > > > > That causes merge conflicts for everybody for years. The cost here is too > high. Again, please, enlighten me how a 1 line +- delta in a file is going to cause any merge conflict outside of +-3 lines from that line? These strings are VERY well located and in areas that should be very rarely touched. Very different than things like large white space clean up. > > c) It'll quickly get us to the damage that is done by > > the loss of this information from the released binary > > product so repairs may begin. > > > > We can begin repairs w/o doing this. 99% of these never end up in binaries > anyway. Oh, now thats false... simple test: find /bin | xargs grep -l \$FreeBSD: | wc find /bin | wc 44/45 files on my 12.1 system. As far as I recall it is more like 99% of our files HAVE these strings in them. > > > d) It'll shorten 1000's of commit messages by the lines: > > While here, remove $FreeBSD$ RCS IDs. > > > > Who cares? I mean, this is not an issue at all. > > Like I've said: there's a real cost to doing this, and the benefits from > doing this are quite small. As someone that's had to deal for years with > partial merges of sweeping commits, please listen when I say that they > always cause unintended pain due to their size. You can repeat yourself, but please give relavent factual cause on how this causes a merge conflict. In most cases it would be a single line delete in an area of the file that is rarely touched. This is NOT like white space cleanup, macro renames, or other global scope changes. It is no worse than the SPDX tagging that was done, and if that had not been caught up in some work flow errors, would of been fine. > Warner -- Rod Grimes rgrimes@freebsd.org