lookupkey absolute path support

lookupkey: Support being given an absolute filename to a file within the
current git repository.

This commit was supported by the NSF-funded DataLad project.

CHANGELOG

@@ -14,6 +14,8 @@ git-annex (6.20171125) UNRELEASED; urgency=medium
   * initremote, enableremote: Really support gpg subkeys suffixed with an
     exclamation mark, which forces gpg to use a specific subkey.
     (Previous try had a bug.)
+  * lookupkey: Support being given an absolute filename to a file
+    within the current git repository.
 
  -- Joey Hess <id@joeyh.name>  Tue, 28 Nov 2017 13:48:44 -0400
 

Command/LookupKey.hs

@@ -1,6 +1,6 @@
 {- git-annex command
  -
- - Copyright 2013 Joey Hess <id@joeyh.name>
+ - Copyright 2013-2017 Joey Hess <id@joeyh.name>
  -
  - Licensed under the GNU GPL version 3 or higher.
  -}
@@ -9,6 +9,7 @@ module Command.LookupKey where
 
 import Command
 import Annex.CatFile
+import qualified Git.LsFiles
 
 cmd :: Command
 cmd = notBareRepo $ noCommit $ noMessages $
@@ -18,10 +19,21 @@ cmd = notBareRepo $ noCommit $ noMessages $
 		(batchable run (pure ()))
 
 run :: () -> String -> Annex Bool
-run _ file = do
-	mk <- catKeyFile file
-	case mk of
+run _ file = seekSingleGitFile file >>= \case
+	Nothing -> return False
+	Just file' -> catKeyFile file' >>= \case
 		Just k  -> do
 			liftIO $ putStrLn $ key2file k
 			return True
 		Nothing -> return False
+
+-- To support absolute filenames, pass through git ls-files.
+-- But, this plumbing command does not recurse through directories.
+seekSingleGitFile :: FilePath -> Annex (Maybe FilePath)
+seekSingleGitFile file = do
+	(l, cleanup) <- inRepo (Git.LsFiles.inRepo [file])
+	r <- case l of
+		(f:[]) | takeFileName f == takeFileName file -> return (Just f)
+		_ -> return Nothing
+	void $ liftIO cleanup
+	return r

doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths.mdwn

@@ -50,3 +50,7 @@ Apparently, git-annex-lookupkey can't handle absolute paths to files to look for
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 I do! I wouldn't even have my job, if it wasn't for git-annex. ;-)
+
+> Which warms the cockles of my heart, Ben! :)
+> 
+> [[fixed|done]] --[[Joey]]

doc/bugs/annex-lookupkey_fails_to_deal_with_absolute_paths/comment_1_b9aa0c69b8841c8fe885a5e2e9ec9a06._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2017-12-08T18:58:18Z"
+ content="""
+This is due to lookupkey not passing the filename through git ls-files like
+most (all?) other commands do.
+
+Using git ls-files would lead to other behavior changes though. It recurses into
+directories. I don't think it makes sense for lookupkey to recurse into
+directories, because its output format does not include the filename, so
+listing a bunch of keys for annexed files is not clear. git annex find
+can already recurse and can use a format with the key and the filename
+that's suited for directory recursion. git annex lookupkey, as plumbing,
+is supposed to be simpler than that.
+
+I suppose lookupkey could normalize absolute file paths, checking if they
+point into the git repository. I don't think that git-annex contains
+such normalization code, and it might be a lot more complicated than it at
+first seems -- git has a lot of wrinkles with submodules, symlinks, etc etc.
+git does not seem to have a suitable command to do it.
+
+So seems the best way is to use git ls-files and detect when it's recursing,
+and exit nonzero then.
+"""]]