> On Tue, Dec 29, 2020, 7:21 PM Glen Barber <g...@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 <free...@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 <g...@freebsd.org> > > > > > AuthorDate: 2020-12-29 14:34:05 +0000 > > > > > Commit: Glen Barber <g...@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. 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. 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. > Warner -- Rod Grimes rgri...@freebsd.org _______________________________________________ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
