when workTreeItems finds a problem with a parameter, don't go on to process it

Part of workTreeItems is trying detect a case
where git porcelain refuses to process a file, and where
git ls-files silently outputs nothing. But, it's hard to perfectly
replicate git's behavior, and besides, git's behavior could change.
So it could be that we warn, but then git ls-files does not skip over
it, and so git-annex also processes it after warning about it.

So, if we think we have a problem with a parameter, display the warning,
and skip processing it at all.

Implementing this was complicated by needing to handle the case where
all command-line parameters get filtered out this way. Which is
different than the case where there are none, because we don't want to
operate on all files in this new case..

doc/bugs/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_1_a2d1112b0a9338b7c093546a985a5f90._comment

@@ -0,0 +1,51 @@
+[[!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. 
+"""]]

doc/bugs/__39__Beyond_symbolic__39___link_error_when_link_is_upstream_of_repo/comment_2_c6e30af134a73bc8b3faee83c7c3b378._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2020-08-06T17:46:11Z"
+ content="""
+I've made it skip processing the file in this case.
+
+Remain unsure if I want to close it now that the behavior is at least not
+weird, or try to more closely replicate git's behavior of what symlinks
+it's ok to be behind and which not.
+"""]]