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

[Ryan Libby]

On Wed, Dec 30, 2020 at 1:19 PM Rodney W. Grimes
<freebsd at gndrsh.dnsmgr.net> wrote:
>
> > On Wed, Dec 30, 2020 at 11:00 AM Warner Losh <imp at bsdimp.com> wrote:
> > >
> > > On Wed, Dec 30, 2020 at 5:04 AM Rodney W. Grimes <freebsd at gndrsh.dnsmgr.net>
> > > wrote:
> > <snip>
> > > > Now what is being just shoved off as nothing is the fact without
> > > > $FreeBSD$ working the ability to backtrace cadence of a file is
> > > > going to be a royal pain in the ass, and basically means the project
> > > > has "lost" versioning of installed product.
> > > >
> > >
> > > You can commit the file you have to a temporary branch, and use a simple
> > > loop to find the file that's closest to it in the main branch with git
> > > tools. It's not that hard and covered in several stack trace posts. It's
> > > far more reliable than $FreeBSD$ since it will show the version that's the
> > > closest to the one you have, in case you moved other later changes in w/o
> > > updating $FreeBSD$.
> >
> > If there's a need for this, it might be useful to describe in or link
> > from the freebsd-git-docs.
> >
> > For exact matches, this almost works:
> >
> > git describe $(git hash-object $file)
> >
> > but not for all branches, I think for git describe $blob you have to be
> > on a branch with the blob in history.  It might also come with some
> > caveats about the hash format.  We might be able either to add some glue
> > around that or work with git upstream.
> >
> > Having a tool to find fuzzy matches would be neat (the blob with the
> > minimum diff).  Does one exist?
>
> This simply well not easily work.  Let me try to explain why.
>
> First take your self OUT of developer mode, and into operations
> and administration.
>
> Take for example all the files in /etc, these files can easily
> at present often be tracked back to exactly what release installed
> them cause the $FreeBSD$ points you at it.  These files are often
> modified by local administrators, and with out knowing what version
> they started out it is a crap shoot to ever figure it out unless
> the local mods are minor and you get lucky.
>
> Contractors are some times hired to go in and upgrade or clean up
> after someone else did work, and not having this information and
> telling them to go dig in git to try and figure out the state of
> there system is pretty much a non-started, well at least it is for
> me.
>
> >
> > Ryan
> >
>
> --
> Rod Grimes                                                 rgrimes at freebsd.org

Disclaimer: I won't pretend to have experience in this area, this is
just musing.

For files that are not disconnected from FreeBSD, as in stuff that we
install and expect or anticipate may be edited on site, it might be
possible to work our own magic to do $FreeBSD$ expansion at build time.
(I'm not sure if this has been discussed previously, or what exactly
that would look like in the build.)

For disconnected files, if there were a tool like, let us imagine,
$ cd /usr/src
$ git whence /some/file
[ output of git describe blob plus a diff ]

Maybe that would be enough?

Ryan