Bugfix: Passing a command a filename that does not exist sometimes did not display an error, when a path to a directory was also passed.

It was relying on segmentPaths to work correctly, so when it didn't,
sometimes the file that did not exist got matched up with a non-null
list of results. Fixed by always checking if each parameter exists.

There are two reason segmentPaths might not work correctly.

For one, it assumes that when the original list of paths
has more than 100 paths, it's not worth paying the CPU cost to
preserve input orders.

And then, it fails when a directory such as "." or ".." or
/path/to/repo is in the input list, and the list of found paths
does not start with that same thing. It should probably not be using
dirContains, but something else.

But, it's not clear how to handle this fully. Consider
when [".", "subdir"] has been expanded by git ls-files to
["subdir/1", "subdir/2"]
-- Both of the inputs contained those results, so there's
no one right answer for segmentPaths. All these would be equally valid:
	[["subdir/1", "subdir/2"], []]
	[[], ["subdir/1", "subdir/2"]]
	[["subdir/1"], [""subdir/2"]]

So I've not tried to improve segmentPaths.

1 files changed, 7 insertions, 0 deletions

diff --git a/CHANGELOG b/CHANGELOG
index 410f64fb8..4145ba2a5 100644
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -1,3 +1,10 @@
+git-annex (6.20170301.2) UNRELEASED; urgency=medium
+
+  * Bugfix: Passing a command a filename that does not exist sometimes
+    did not display an error, when a path to a directory was also passed.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 02 Mar 2017 12:51:40 -0400
+
 git-annex (6.20170301.1) unstable; urgency=medium
 
   * Fix reversion in yesterday's release that made SHA1E and MD5E backends