On Wed, Dec 30, 2020 at 2:31 PM Rodney W. Grimes <free...@gndrsh.dnsmgr.net> wrote:
> > On Wed, Dec 30, 2020 at 5:13 AM Rodney W. Grimes < > free...@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 <g...@freebsd.org> > > > > > > AuthorDate: 2020-12-29 14:34:05 +0000 > > > > > > Commit: Glen Barber <g...@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. > > > > > > > > > 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. > > > > > > > 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. > > 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. > > 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. 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. Warner _______________________________________________ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
