Date: Wed, 30 Dec 2020 12:00:26 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <rgrimes@freebsd.org> Cc: Glen Barber <gjb@freebsd.org>, Kyle Evans <kevans@freebsd.org>, src-committers <src-committers@freebsd.org>, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 70e64ba44941 - main - release.sh: Update GITROOT URL Message-ID: <CANCZdfpAFnnLd=9xs9QZkUGWn2UzhM0a5pOyhEUW3La3pbnAaA@mail.gmail.com> In-Reply-To: <202012301204.0BUC4qX7081946@gndrsh.dnsmgr.net> References: <CANCZdfoE5KuWPHNmqK1=W0TW6LE8sxwBV51SndoDYwE3zXyFOw@mail.gmail.com> <202012301204.0BUC4qX7081946@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 30, 2020 at 5:04 AM Rodney W. Grimes <freebsd@gndrsh.dnsmgr.net> wrote: > > On Tue, Dec 29, 2020, 7:21 PM Glen Barber <gjb@freebsd.org> wrote: > > > > > On Tue, Dec 29, 2020 at 06:36:45PM -0600, Kyle Evans wrote: > > > > On Tue, Dec 29, 2020, 18:18 Rodney W. Grimes < > freebsd@gndrsh.dnsmgr.net> > > > > wrote: > > > > > > > > > > The branch main has been updated by gjb: > > > > > > > > > > > > URL: > > > > > > > > > https://cgit.FreeBSD.org/src/commit/?id=70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > > > > > > > commit 70e64ba4494190e64ab8faa04d744182d420c275 > > > > > > Author: Glen Barber <gjb@FreeBSD.org> > > > > > > AuthorDate: 2020-12-29 14:34:05 +0000 > > > > > > Commit: Glen Barber <gjb@FreeBSD.org> > > > > > > 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? > > > > > > > > > > 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? > > > > > > > > > > > > > > > > I don't see any particularly compelling reason to strip these tags, > > > > personally. I stripped them from caroot because we embedded them in > > > > generated files and it creates a lot of noise on updatecerts that I > do > > > not > > > > need/want, while providing no value to justify the noise for a purely > > > > generated file. > > > > > > They are not used/updated, so why keep a tag that does not expand to > any > > > useful information? > > > > > > > Deleting all the $FreeBSD$ in on go is massively unwise (or as the > British > > might say, "a very brave plan"). It will screw up MFCs on an epic scale > for > > years for no real benefit to pay for that extra developer time. It itself > > can't be MFCd. It's a terrible idea. We should not be deleting them, > except > > judiciously for things that cannot be MFCd. With the subversion exporter, > > they will live on in stable/12. > > Just exactly how would this screw up MFC's on an epic scale? Your > NOT going to merge this massive commit, which as long as you don't > touch lines near $FreeBSD$ things should just be fine. > By screwing them up. I'm sorry you don't have enough experience to know all the ways it causes pain: (1) merge conflicts often enough to require developer time to sort out (2) partial merges causing confusion when other changes need to make them. > Now commiting a change to $FreeBSD$ along with OTHER changes is > a sure fire way to cause a MFC conflict, but not anything major > that can not be dealt with via conflict resolution. > Right. We're inflicting conflict resolution pain over a large number of commits. This costs developer time, even if it's just a little. Removing $FreeBSD$ simply isn't worth that developer time. > Now what is being just shoved off as nothing is the fact without > $FreeBSD$ working the ability to backtrace cadence of a file is > going to be a royal pain in the ass, and basically means the project > has "lost" versioning of installed product. > You can commit the file you have to a temporary branch, and use a simple loop to find the file that's closest to it in the main branch with git tools. It's not that hard and covered in several stack trace posts. It's far more reliable than $FreeBSD$ since it will show the version that's the closest to the one you have, in case you moved other later changes in w/o updating $FreeBSD$. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpAFnnLd=9xs9QZkUGWn2UzhM0a5pOyhEUW3La3pbnAaA>