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

[Warner Losh]

On Wed, Dec 30, 2020, 11:03 PM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
wrote:

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

Except we don't do that anymore. Nobody dies that any more. They use build
IDs instead. They use proper CM. They have traceability through other means.

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

Yes. It is gone. The industry has moved on and no longer thinks this is a
good idea.

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

Lots of changes happen near the start of the file, near where the $FreeBSD$
lives. This is especially true for shorter files.

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

It is the default in current to omit these. I checked a current system.

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

The fact you are demanding work from me makes you acceptance irrelevant. If
it causes any extra work, it's too high a price. My WAG was to try to put
some numbers around it based on doing hundreds of MFCs.

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

Git likes smaller changes. One huge commit would become un-revertable
without a lot of effort fairly quickly. Small changes could be reverted
more easily. The only snag is the one email per commit rather than per
push...

I'm kinda snarky about this because you are demanding we do this in a way I
know will cause problems because when we've done big sweeping commits in
the past they have caused problems, even ones that people at the time
thought would be no trouble.  Done all at once, there will be additional
work for me and other frequent MFCers.

It's not my burden to disprove everything you throw up. The project has a
way of creating problems for itself by doing this in some philosophically
right way that ignores history and experiences the project has had. I'm
just asking that we not do it please.

Warner

> Warner
> --
> Rod Grimes
> rgrimes at freebsd.org
>