>   err = got_path_skip_common_ancestor(&child,
>       got_worktree_get_root_path(worktree), abspath_in_worktree);
>   if (err)
>         goto done;
>   if (openat(worktree_fd, child, ...) == -1) {
>         err = got_error_from_errno2("openat", abspath_in_worktree);
>         free(child);
>         goto done;
>   }
>   free(child);
>
> We can derive relative paths from absolute ones in this way.
> Any function which has access to struct got_worktree and an absolute path
> that points inside this worktree should be able to use openat() to open the
> corresponding file. Provided an fd and worktree root abspath are both stored
> in struct got_worktree. Similarly for got_repository and the tempdir.

I definitely see the benefit of this solution. I'm concerned that adding
this extra step to every open() call will add too much noise, but I'll try
this solution in a section of code first, to be sure. Likely, some places
will still make more sense with relative paths (such as in the first patch
I wrote).

> (I also hope that capsicum will be OK with multiple path components in the
> path argument of openat(), like this: openat(open("/one"), "two/three");
> If not, an fd for every intermediate directory would be required, which
> would be very awkward to handle.)

Yes, capsicum is fine with this. It only requires that the path have no ".."s
in it.