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

[Rodney W. Grimes]

> On Wed, Dec 30, 2020 at 5:13 AM Rodney W. Grimes <freebsd at 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 <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?
> > > >
> > >
> > > 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.

> > 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.

> 
> 
> > > > 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.

> 
> 
> > 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.

> > 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.

> 
> > 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.

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.

> Warner
-- 
Rod Grimes                                                 rgrimes at freebsd.org