From owner-dev-commits-src-main@freebsd.org Wed Dec 30 22:20:57 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 4D2194D0AB6 for ; Wed, 30 Dec 2020 22:20:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5m2d1VTsz4lLN for ; Wed, 30 Dec 2020 22:20:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72e.google.com with SMTP id 186so15136959qkj.3 for ; Wed, 30 Dec 2020 14:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+VKpwut2qzUbpl3QN+xi1X6Zo/MvuuPC3a5viwb7ixc=; b=afaMKFe9Gw/3qywv0YhcFNJwHcmDVhJiuqs5AdJjbJVJTAUS7puwO8dcr/kR2WS4mQ rZ/4iyDE43T6BNqIFiF6TmVExWIO0sHYKOF1/U6b2zp20wXLOu57qJLH2UboW+lCOcjy xLCS6W6H2UwJYSUWZcLh0aN91H96Hb6+KLc1DY2lsYwYW3ahD1nCMO78jL16VHf+Ifxq 25c5FYZ3xD40gJ/L+IsO4nEbcGWOy0BQVMPIRD/zgyE6ACy5DKJzT+sgAlUZfKpXdX/r NakzZEKNkjshgOnUeg9Kh3yeGxadhg196cvIDmZpeeab3VCGo7q4cGep1pQR2sWPyfn/ iVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+VKpwut2qzUbpl3QN+xi1X6Zo/MvuuPC3a5viwb7ixc=; b=PUSsuVh3BmCAXagU6D+n71jtZqGvMxx9Ay2lHnoVZDscaJraV8Bs47zAQlmniUo3Ro 8TeiQtc8ZE45gIylMnWpptSMIkESiGuX+7epxAZEjzG5JLpDOGlZf58FavybHXchv8wB 6IAgChkMVzt+zmU5ayw6Qe590x2xNy/fnDJWEMhB/Cac1MSGuDXu0ZYDIPea16cfWrLy V6kIsb5PMFQXuxN1mFLpheyRLY6OfcSZIE8Y939X1Z7GSaKmLkZAFfePsxU2D+Z0zNw7 yEnX2lWCgkncyEqFcN/Nb5K+IuCiyXw0M8Fgvvt2WgsiW3ybSLfbJ+vYY/v3IAO3ZMch eKIw== X-Gm-Message-State: AOAM531oeU/ZoCkMQ7yv7XniVEI5HPUiYGl+5TAZLIOD1TUYK9PQB73T M7Z8vyzaZHxhdhS2wnD4OUK55HXV38Y77qbPfxodIg== X-Google-Smtp-Source: ABdhPJxq27V3scJQg1pYwtatAmKYQE3f4TlNKWiuQYARgO7g6E5OTCqML0/flrj5bp+Z74ZorF5QmcjcgHJWm2HSuYY= X-Received: by 2002:a37:4a4e:: with SMTP id x75mr55571211qka.89.1609366856350; Wed, 30 Dec 2020 14:20:56 -0800 (PST) MIME-Version: 1.0 References: <202012302131.0BULVETD083618@gndrsh.dnsmgr.net> In-Reply-To: <202012302131.0BULVETD083618@gndrsh.dnsmgr.net> From: Warner Losh Date: Wed, 30 Dec 2020 15:20:45 -0700 Message-ID: Subject: Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL To: "Rodney W. Grimes" Cc: Glen Barber , src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org X-Rspamd-Queue-Id: 4D5m2d1VTsz4lLN X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 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 22:20:57 -0000 On Wed, Dec 30, 2020 at 2:31 PM Rodney W. Grimes wrote: > > On Wed, Dec 30, 2020 at 5:13 AM Rodney W. Grimes < > freebsd@gndrsh.dnsmgr.net> > > 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. > Your opinion has been noted. > > > 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. > You describe a source code management nightmare that $FreeBSD$ might be able to solve a subset of cases, but other methods will solve them better. > > > > > > > > > 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. > I am. It's an extremely poor fit to git, has extreme resistance in git upstream and the available git support is too limited to be useful. Big effort, low reward item in a volunteer project generally means it won't happen when there's other workarounds that are simpler and easier. > > > > > > > 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. > Let's do some math. We have about 10k commits on a stable branch, give or take. My experience with MFCing suggests that 5% of these will have a merge conflict that needs to be resolved. Each one of these conflicts takes 5 minutes to resolve because it breaks up the flow of the commits, etc. So ~500 commits for ~5 minutes is ~40 hours. We've just wasted an entire week of developer time for doing it all at once, vs almost 0 for doing it incrementally. > > 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. > On my system, the numbers are quite different: % find /*bin /usr/*bin -type f | xargs grep -la '$FreeBSD:' | wc 4 4 64 3:14pm rebo:[245]> find /*bin /usr/*bin -type f | wc 1032 1032 16791 And all 4 binaries are from 2016 and appear to be 'stale' leftovers. > > 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. I have given numbers. We'd be wasting a week's time of all our developers, give or take. 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. > There's value in the SPDX stuff, which we also did piecemeal, and which also caused me grief when I MFC'd stuff because it was done in large batches, and merged incrementally. Warner