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

Warner Losh imp at bsdimp.com
Wed Dec 30 04:02:33 UTC 2020


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.

Warner

>


More information about the dev-commits-src-main mailing list