[[!comment format=mdwn
 username="joey"
 subject="""comment 1"""
 date="2020-08-06T16:01:46Z"
 content="""
Really, the shell is the only thing that knows cd has been used with a symlink,
the real cwd is what getCurrentDirectory returns, same as getcwd(3).

(I think this is a bad design decision on the part of shells, it often
leads to various confusion and odd behavior. A good example of this is
that, if you cd bar/dir, which is a symlink to foo/dir, and both
bar/file and foo/file exist, what does rm ../file delete? Not what the
shell prompt's `bar>` suggests!)

What this code needs to do is stop traversing the path and checking for
symlinks when it reaches the top of the working tree. But I'm not currently
seeing a good way to do that. It would need to examine the path for
symlinks and resolve them. Like canonicalizePath, but don't want to
canonicalize the part of the path inside the working tree, eg a symlink
"./foo" should not be canonicalized to "./bar". But how does it know where
inside working tree part begins when there are symlinks involved? Probably
I'm missing something simple which git does to deal with this.

(Also, canonicalizePath or anything like it does add a certian amount of
overhead for every file passed to git-annex on the command line, just for
this edge case. The current code does 2 stats, but this would be stats
all the way up the path.)

It also looks like the nearby code `hidden currbranch relf`
will not work in this same case, because relf is "../../alink/repo/f0".
In that case it will display "not found" and really fail to process
the file.

In a way the really surprising thing is not that it rejects this file with
"is beyond a symbolic link" but that the file then goes on to be processed
anyway. Because this code only displays a warning, and is written with the
naive hope that it will manage to replicate git's porcelain behavior.
But then git ls-files goes on to list the file anyway, so it's processed
anyway.

I think it should certianly, if it warns about a file, not pass it into git
ls-files. So the warning really becomes an error and that surprise is
avoided.

That might be enough to consider this dealt with, without using
canonicalizePath. There would then be an inconsistency that `git add` etc
can be used with that path, while `git annex add` etc reject it as beyond
a symbolic link. But git-annex is not obliged to copy git's behavior in what
path situations it will accept and rejecting this particular one does not seem
like a hardship to the user. 
"""]]
