git: 70e64ba44941 - main - release.sh: Update GITROOT URL

[Rodney W. Grimes]

> On Tue, Dec 29, 2020, 7:21 PM Glen Barber <gjb at 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 at 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 at FreeBSD.org>
> > > > > AuthorDate: 2020-12-29 14:34:05 +0000
> > > > > Commit:     Glen Barber <gjb at 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                                                 rgrimes at freebsd.org