On Fri, Oct 30, 2020 at 01:02:37PM -0400, Ed Maste wrote:
> I've started looking at what would be involved to include got in the
> FreeBSD base system, based on naddy's work in the FreeBSD ports tree.
> Here are some notes on what I've done so far.
> 
> I started with openbsd-compat from the 0.41 port, along with the
> port's patches, and have been rebasing that since. The current wip is
> here: https://github.com/emaste/got/tree/freebsd-main
> 
> I made some changes for miscellaneous Mk differences - MAN= instead of
> NOMAN=yes, LIBADD instead of LDADD/DPADD. These changes are not
> reasonable for upstream, of course.
> 
> I've added a .cirrus.yml config to build on FreeBSD and later test in
> Cirrus-CI; the test suite is not yet being run. Example Cirrus run:
> https://cirrus-ci.com/build/5352361658941440
> 
> I encountered many warnings when I inserted this repo into the FreeBSD
> tree and built with a higher WARNS= setting; some of these are
> addressed in the repo linked above. A number are changes to the port's
> openbsd-compat. There were many signedness comparison warnings from
> int loop indices; I've changed them to be size_t. This is the first
> change reasonable for upstream; I can post the patches here shortly.
> 

I am very happy to hear that Got is suitable for this purpose.

I don't think it would be in anyone's interest if our code bases diverge.
Please feel free to propose any changes that you believe are suitable for
upstream.

> Finally, I have some interns working on FreeBSD until the end of the
> year and one of them is looking at applying Capsicum to got. I hope
> that we can make some relatively small changes in an
> upstream-palatable way that we can then build on with local changes.
> At a high level we will want to open directory fds for each of the
> paths currently being unveil()ed, and make all file access relative to
> one of those via openat, readlinkat, etc.

Got's high-level repo_open and worktree_open operations should be able
to accommodate file descriptors for relevant directories. Do not be afraid
of changing APIs anywhere in the Got tree if it helps. None of the APIs are 
considered stable yet, not even those in the public include/ directory.

The work tree status walk has already been partly converted to openat()
and friends, and there is some work left to do here.
My idea was to ensure that Got commands which are in progress will not
operate on new versions of files or directories that happen to be replaced
by third party tools while Got is operating on the work tree.
So instead of traversing directories by path, we traverse directory entry
names associated with a directory file descriptor.
If this model of passing file descriptors around fits capsicum as well
then getting more done in this area looks like a win-win to me.

If you have interns interested in implementing Git-specific algorithms,
protocols, or other features that Got is still lacking, I would be happy
to discuss with them. There is a lot left to do before this project will
be ready for a stable release which offers a full set of functionality
expected from a stand-alone version control system.