Stefan Sperling:

> The file logged in your example is located in a Got work tree.
> I think good a first step towards clearing up the confusion is to
> avoid calling got_repo_map_path() if we have a work tree.

But the unveil/realpath problem arises when the work tree is
irrelevant!

Actually, the example I gave was bad because of the subdirectory.
Let's try again:

$ cd /home/naddy/got    # work tree
$ got log -r /home/naddy/got.git Makefile
got: home/naddy/got/Makefile: no such entry found in tree

The trigger of the problem is "-r repo", which causes the worktree==NULL
branch to be taken.

So in the example above, the -r repo is redundant since it just
specifies the very same repository that can be derived from the
work tree.  However, it makes perfect sense to reference a DIFFERENT
repository while in a worktree:

$ cd /home/naddy/got    # worktree
$ got log -r /home/naddy/openbsd.git Makefile
got: home/naddy/got/Makefile: no such entry found in tree

It's irrelevant whether a file ./Makefile exists in the worktree.
Is there any interpretation for "log -r repo path" other than "path
is relative to repo" that still makes sense?

-- 
Christian "naddy" Weisgerber                          naddy@mips.inka.de