I'd like clarification on a few points: If I have a path that I know is
relative to one of our three fds (the worktree, the repo, /tmp), as
well as the fd itself, is that considered a relative or absolute path?

Another question, sort of a continuation of the first:
From what I know about the code, I think that files under these
main directories will always stay underneath them. ie. if I have
a path to a file in the worktree, the path to the worktree itself
within that path won't ever change. Is this true?

I'm having some trouble articulating what I mean. My point is
that it appears reasonable to replace truly absolute paths
("/one/two/three") with a pair of fd and relative path (an fd from
open("/one/two"), "three").


On Fri, Dec 4, 2020 at 7:56 AM Stefan Sperling <stsp@stsp.name> wrote:
>
> On Fri, Dec 04, 2020 at 07:33:46AM -0800, Yang Zhong wrote:
> > Yes, I've done something similar to that in my proof-of-concept.
> > Instead of an extern, I made a function that opens /tmp and
> > saves the fd.
>
> Right, that's good. The idea with a global variable came about
> when I tried to find ways which reduce the amount of diff created
> for upstream code when tweaking function parameters to pass fds.
>
> > Speaking of mkostempsat: I've been poking around my changes
> > and it seems like many of them depend on mkostempsat, since
> > I often change absolute paths to ones relative to fds. Right now
> > I've written a stand-in opentemp function that (I think) does
> > something equivalent, but it's certainly not something that I
> > can actually commit.
>
> An important point about absolute vs. relative paths:
>
> Version control systems deal a lot with paths, and often have to
> perform computations on paths such as splitting, appending, etc.
>
> Like Subversion, Got tries to use only absolute paths internally.
>
> In Subversion's case this is being enforced by error checking at the
> library API level, such that passing relative paths becomes impossible.
>
> Got's library is less strict, but the goal of most, if not all, realpath(3)
> calls is to ensure that we're dealing in absolute paths. Some code will
> probably misbehave if relative paths are passed around instead.
>
> So if you can, please try to avoid switching to relative paths. If a
> system call requires a relative path, it should generally be possible to
> convert an absolute path into a relative one on demand. The opposite
> conversion is difficult, hence the need for functions like realpath(3).