Re: git tools for building in base?

On Wed, Nov 25, 2020 at 6:16 AM tech-lists <tech-lists_at_zyxst.net> wrote:

> Hi,
>
> On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote:
> >On Tue, Nov 24, 2020 at 2:19 PM tech-lists <tech-lists_at_zyxst.net> wrote:
> >
> >> As subject - what will there be in base to interact with the new git
> repo?
> >> I mean, right now, for svn there is svnlite. What for git?
> >>
> >'pkg add git' is your choice now.
> >
> >> Shouldn't it be in base before the move to git?
> >
> >We will have got (from OpenBSD: Game Of Trees) in the future. It isn't
> >quite there yet, however, so it's not in base.
>
> Do you agree that this situation is a bad look for an *operating system* ?
> Having to depend on a third-party tool to stay up-to-date and secure.
>

In the long term, perhaps. During a short-term transition, it seems
acceptable.


> In multiple locations it is said that installing a port is *at your own
> risk*. Personally, I'd like the official updating tool to have had the
> same level of analysis (and so the same level of "risk") on it as the base
> OS,
> (and also be under the same licence).
>

You can establish your own chain of trust to the sources, you can start
here https://mirrors.edge.kernel.org/pub/software/scm/git/ if building from
ports or installing a package is deemed to be too insecure.


> I mean, shouldn't all the basic tools be present in an OS, at least in
> order to update it? And *then* migrate to the update method?
>

git is a perfectly fine tool. Moving to git has a number of advantages to
the project, so we must weigh the many different factors in doing that and
not let a single item gate the entire process if that single item doesn't
add enough value. -current is for bleeding edge users, and the cost /
benefit analysis is skewed heavily towards the convenience of the
developers when a choice needs to be made. In this case, the choice was
made to progress with the cutover of the repo while allowing the natural
development of got to proceed in parallel. One way to help this situation
would be to contribute code to OpenBSD's got to help it mature to the point
we can include it in the base system. There's logistical issues as well:
today got only clones via ssh, and the typical distribution of git is via
the git or https protocols (though developers often push commits via ssh).
To overcome these limitations, we'd have to stand up additional
infrastructure to allow for anonymous ssh into mirrors. This is in the
planning stages, but is taking a back seat at the moment to getting the
basic infrastructure up and running.


> >When we migrated from CVS to Subversion, we didn't grow svnlite in
> >the base for many months after the conversion.
>
> A mistake then and a mistake now with svn to git IMO.


It wasn't considered a mistake at the time, nor do I consider this a
mistake now. At the time Peter Wemm did the cutover, moving to a SCM that
had atomic commits was considered a higher priority than necessarily
needing svn in the base system. So our adaptation of svn back in the day
proceeded in parallel with a repackaging of svn to allow a minimal version
to be included with the base system.

Warner