Re: got(1) in base consideration

On 5/5/25 03:58, Konstantin Belousov wrote:
> On Sun, May 04, 2025 at 08:50:46PM -0500, Kyle Evans wrote:
>> Hi,
>>
>> I've been toying around with the idea of pulling got(1) into base, but
>> hidden off into /usr/libexec and not supporting it for general usage. The
>> idea would instead be to provide a script or two as a user-facing interface
>> to do the bare minimum to functionally maintain a local copy of our git
>> repos.
>>
>> However, I've run into some logistics issues that I wanted to throw out for
>> some opinions.  The main issue I've run into is that while got's repository
>> layout is binary-compatible with git, it won't setup worktrees the same way.
>> Additionally, it really doesn't like the traditional organization of a git
>> clone, where you'd have your .git directory inside of your primary worktree
>> (e.g., /usr/src and /usr/src/.git).
>>
>> I don't think this is really a deal-breaker, my proposal to start with would
>> be that we clone the repositories off into /var/db/got/$repo or some such
>> and setup the worktrees in the traditional place.  git can `worktree add`
>> from these repos successfully, so one could setup a git-compatible worktree
>> at least without having to re-clone the entire repository, but that brings
>> me to the second caveat noted in the paragraph above: the worktree format
>> isn't compatible.
>>
>> We could write a script that'll bridge the gap, but AFAICT that means that
>> we'd effectively have to just blow away the existing got worktree at
>> /usr/src and recreate it, with sensible guardrails in place to try and avoid
>> losing any uncommitted work.  That's sort of ugly and I don't really know
>> how to feel about it, thus this e-mail.
>>
>> Thoughts?
> 
> What is the intended audience of the setup?
> Who would not install normal git port but still want /usr/src populated?
> For what purpose?

Hi,

I'm thinking less about src here and more about ports, where 
end-user/sysadmin may just want a simple mechanism to keep their ports 
tree updated (as a replacement for, e.g., portsnap).

Thanks,

Kyle Evns