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

[Rodney W. Grimes]

> On Wed, Dec 30, 2020 at 2:31 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> wrote:
> 
> > > 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.
> >
> 
> Your opinion has been noted.
> 
> 
> > > > 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.
> >
> 
> You describe a source code management nightmare that $FreeBSD$ might be
> able to solve a subset of cases, but other methods will solve them better.

This is not a source code management nightmare, it is a traceability
of production items, this "feature" has been in BSD since /bin/what
was written to extract SCCS id's out of binary files.  That got
broken cause we stoped putting them in, but the strings of $FreeBSD$
have always been in the binaries.  This gives traceability.

> > >
> > > > > > 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.
> >
> 
> I am. It's an extremely poor fit to git, has extreme resistance in git
> upstream and the available git support is too limited to be useful. Big
> effort, low reward item in a volunteer project generally means it won't
> happen when there's other workarounds that are simpler and easier.

So basically anything that git doesnt fit is now gone.. *sigh*

> > > > 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.
> >
> 
> Let's do some math. We have about 10k commits on a stable branch, give or
> take. My experience with MFCing suggests that 5% of these will have a merge
> conflict that needs to be resolved. Each one of these conflicts takes 5
> minutes to resolve because it breaks up the flow of the commits, etc. So
> ~500 commits for ~5 minutes is ~40 hours. We've just wasted an entire week
> of developer time for doing it all at once, vs almost 0 for doing it
> incrementally.

Your math is not math if you claim that this delta would cause 5%
conflicts.  MOST MFC conflicts occur because of missing interveing
commits.

You still have not explained how a 1 line delta removing a line
is likely to cause any conflict at all, and I continue to assert
it is very unlikely to as this 1 line is almost always in other
lines that are very very rarely if ever changed.

> 
> > > 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.
> >
> 
> On my system, the numbers are quite different:
> % find /*bin /usr/*bin -type f | xargs grep -la '$FreeBSD:' | wc
>        4       4      64
> 3:14pm rebo:[245]> find /*bin /usr/*bin -type f | wc
>     1032    1032   16791
> 
> And all 4 binaries are from 2016 and appear to be 'stale' leftovers.

My guess would be your system is NOT from a production release
of FreeBSD, probably compiled with a STRIP_FBSDID defined.

I checked /bin on 11.2, 12.0 and 12.1 same results, all but 2 files.

> 
> > > 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.
> 
> 
> I have given numbers. We'd be wasting a week's time of all our developers,
> give or take.

I do not accept your WAG 5% as a realistic number.

> 
> 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.
> >
> 
> There's value in the SPDX stuff, which we also did piecemeal, and which
> also caused me grief when I MFC'd stuff because it was done in large
> batches, and merged incrementally.

Just because you see no value in FreeBSD, does not make it have no
value.  I would argue it has more value that SPDX.  At least it
is used programatically to create traceability in the production
releases.

> Warner
-- 
Rod Grimes                                                 rgrimes at freebsd.org