Merge branch 'master' into concurrentprogress

Annex/Branch.hs

@@ -414,6 +414,7 @@ stageJournal jl = withIndex $ do
 	g <- gitRepo
 	let dir = gitAnnexJournalDir g
 	(jlogf, jlogh) <- openjlog
+	liftIO $ fileEncoding jlogh
 	withJournalHandle $ \jh -> do
 		h <- hashObjectStart g
 		Git.UpdateIndex.streamUpdateIndex g

Annex/Content.hs

@@ -9,6 +9,7 @@
 
 module Annex.Content (
 	inAnnex,
+	inAnnex',
 	inAnnexSafe,
 	inAnnexCheck,
 	lockContent,

Assistant/WebApp/Configurators/Local.hs

@@ -347,8 +347,9 @@ getFinishAddDriveR drive = go
 combineRepos :: FilePath -> String -> Handler Remote
 combineRepos dir name = liftAnnex $ do
 	hostname <- fromMaybe "host" <$> liftIO getHostname
-	hostlocation <- fromRepo Git.repoLocation
-	liftIO $ inDir dir $ void $ makeGitRemote hostname hostlocation
+	mylocation <- fromRepo Git.repoLocation
+	mypath <- liftIO $ relPathDirToFile dir mylocation
+	liftIO $ inDir dir $ void $ makeGitRemote hostname mypath
 	addRemote $ makeGitRemote name dir
 
 getEnableDirectoryR :: UUID -> Handler Html

CmdLine/GitAnnex.hs

@@ -22,6 +22,7 @@ import qualified Command.Move
 import qualified Command.Copy
 import qualified Command.Get
 import qualified Command.LookupKey
+import qualified Command.ContentLocation
 import qualified Command.ExamineKey
 import qualified Command.FromKey
 import qualified Command.RegisterUrl
@@ -152,6 +153,7 @@ cmds = concat
 	, Command.Ungroup.cmd
 	, Command.Vicfg.cmd
 	, Command.LookupKey.cmd
+	, Command.ContentLocation.cmd
 	, Command.ExamineKey.cmd
 	, Command.FromKey.cmd
 	, Command.RegisterUrl.cmd

Command/Add.hs

@@ -52,7 +52,7 @@ seek ps = do
 	matcher <- largeFilesMatcher
 	let go a = flip a ps $ \file -> ifM (checkFileMatcher matcher file <||> Annex.getState Annex.force)
 		( start file
-		, stop
+		, startSmall file
 		)
 	skipdotfiles <- not <$> Annex.getFlag (optionName includeDotFilesOption)
 	go $ withFilesNotInGit skipdotfiles
@@ -61,6 +61,16 @@ seek ps = do
 		, go withFilesUnlocked
 		)
 
+{- Pass file off to git-add. -}
+startSmall :: FilePath -> CommandStart
+startSmall file = do
+	showStart "add" file
+	showNote "non-large file; adding content to git repository"
+	next $ do
+		params <- forceParams
+		Annex.Queue.addCommand "add" (params++[Param "--"]) [file]
+		next $ return True
+
 {- The add subcommand annexes a file, generating a key for it using a
  - backend, and then moving it into the annex directory and setting up
  - the symlink pointing to its content. -}
@@ -260,16 +270,19 @@ addLink :: FilePath -> Key -> Maybe InodeCache -> Annex ()
 addLink file key mcache = ifM (coreSymlinks <$> Annex.getGitConfig)
 	( do
 		_ <- link file key mcache
-		params <- ifM (Annex.getState Annex.force)
-			( return [Param "-f"]
-			, return []
-			)
+		params <- forceParams
 		Annex.Queue.addCommand "add" (params++[Param "--"]) [file]
 	, do
 		l <- link file key mcache
 		addAnnexLink l file
 	)
 
+forceParams :: Annex [CommandParam]
+forceParams = ifM (Annex.getState Annex.force)
+	( return [Param "-f"]
+	, return []
+	)
+
 cleanup :: FilePath -> Key -> Maybe InodeCache -> Bool -> CommandCleanup
 cleanup file key mcache hascontent = do
 	ifM (isDirect <&&> pure hascontent)

Command/ContentLocation.hs

@@ -0,0 +1,32 @@
+{- git-annex command
+ -
+ - Copyright 2015 Joey Hess <id@joeyh.name>
+ -
+ - Licensed under the GNU GPL version 3 or higher.
+ -}
+
+module Command.ContentLocation where
+
+import Common.Annex
+import Command
+import Annex.Content
+import Types.Key
+
+cmd :: [Command]
+cmd = [noCommit $ noMessages $
+	command "contentlocation" (paramRepeating paramKey) seek
+		SectionPlumbing "looks up content for a key"]
+
+seek :: CommandSeek
+seek = withKeys start
+
+start :: Key -> CommandStart
+start k = do
+	liftIO . maybe exitFailure putStrLn
+		=<< inAnnex' (pure True) Nothing check k
+	stop
+  where
+	check f = ifM (liftIO (doesFileExist f))
+		( return (Just f)
+		, return Nothing
+		)

Command/ImportFeed.hs

@@ -146,15 +146,17 @@ findDownloads u = go =<< downloadFeed u
 
 {- Feeds change, so a feed download cannot be resumed. -}
 downloadFeed :: URLString -> Annex (Maybe Feed)
-downloadFeed url = do
-	showOutput
-	uo <- Url.getUrlOptions
-	liftIO $ withTmpFile "feed" $ \f h -> do
-		fileEncoding h
-		ifM (Url.download url f uo)
-			( parseFeedString <$> hGetContentsStrict h
-			, return Nothing
-			)
+downloadFeed url
+	| Url.parseURIRelaxed url == Nothing = error "invalid feed url"
+	| otherwise = do
+		showOutput
+		uo <- Url.getUrlOptions
+		liftIO $ withTmpFile "feed" $ \f h -> do
+			hClose h
+			ifM (Url.download url f uo)
+				( parseFeedString <$> readFileStrictAnyEncoding f
+				, return Nothing
+				)
 
 performDownload :: Opts -> Cache -> ToDownload -> Annex Bool
 performDownload opts cache todownload = case location todownload of

Command/Info.hs

@@ -238,7 +238,12 @@ showStat s = maybe noop calc =<< s
 repository_mode :: Stat
 repository_mode = simpleStat "repository mode" $ lift $
 	ifM isDirect 
-		( return "direct", return "indirect" )
+		( return "direct"
+		, ifM (fromRepo Git.repoIsLocalBare)
+			( return "bare"
+			, return "indirect"
+			)
+		)
 
 remote_list :: TrustLevel -> Stat
 remote_list level = stat n $ nojson $ lift $ do

Command/Proxy.hs

@@ -15,6 +15,7 @@ import Utility.Env
 import Annex.Direct
 import qualified Git.Sha
 import qualified Git.Ref
+import qualified Git.Branch
 
 cmd :: [Command]
 cmd = [notBareRepo $
@@ -28,19 +29,20 @@ start :: [String] -> CommandStart
 start [] = error "Did not specify command to run."
 start (c:ps) = liftIO . exitWith =<< ifM isDirect
 	( do
-		g <- gitRepo
-		withTmpDirIn (gitAnnexTmpMiscDir g) "proxy" go
+		tmp <- gitAnnexTmpMiscDir <$> gitRepo
+		withTmpDirIn tmp "proxy" go
 	, liftIO $ safeSystem c (map Param ps)
 	)
   where
 	go tmp = do
 		oldref <- fromMaybe Git.Sha.emptyTree
 			<$> inRepo Git.Ref.headSha
-		exitcode <- liftIO $ proxy tmp
+		exitcode <- proxy tmp
 		mergeDirectCleanup tmp oldref
 		return exitcode
 	proxy tmp = do
-		usetmp <- Just . addEntry "GIT_WORK_TREE" tmp  <$> getEnvironment
-		unlessM (boolSystemEnv "git" [Param "checkout", Param "--", Param "."] usetmp) $
-			error "Failed to set up proxy work tree."
-		safeSystemEnv c (map Param ps) usetmp
+		usetmp <- liftIO $ Just . addEntry "GIT_WORK_TREE" tmp  <$> getEnvironment
+		unlessM (isNothing <$> inRepo Git.Branch.current) $
+			unlessM (liftIO $ boolSystemEnv "git" [Param "checkout", Param "--", Param "."] usetmp) $
+				error "Failed to set up proxy work tree."
+		liftIO $ safeSystemEnv c (map Param ps) usetmp

Git/CheckIgnore.hs

@@ -31,10 +31,13 @@ type CheckIgnoreHandle = CoProcess.CoProcessHandle
  -
  - The first version of git to support what we need is 1.8.4.
  - Nothing is returned if an older git is installed.
+ -
+ - check-ignore does not support --literal-pathspecs, so remove that
+ - from the gitGlobalOpts if set.
  -}
 checkIgnoreStart :: Repo -> IO (Maybe CheckIgnoreHandle)
 checkIgnoreStart repo = ifM supportedGitVersion
-	( Just <$> (CoProcess.rawMode =<< gitCoProcessStart True params repo)
+	( Just <$> (CoProcess.rawMode =<< gitCoProcessStart True params repo')
 	, return Nothing
 	)
   where
@@ -42,6 +45,9 @@ checkIgnoreStart repo = ifM supportedGitVersion
 		[ Param "check-ignore" 
 		, Params "-z --stdin --verbose --non-matching"
 		]
+	repo' = repo { gitGlobalOpts = filter (not . pathspecs) (gitGlobalOpts repo) }
+	pathspecs (Param "--literal-pathspecs") = True
+	pathspecs _ = False
 
 supportedGitVersion :: IO Bool
 supportedGitVersion = do

Git/DiffTree.hs

@@ -36,12 +36,12 @@ isDiffOf diff f = case getTopFilePath f of
 {- Diffs two tree Refs. -}
 diffTree :: Ref -> Ref -> Repo -> IO ([DiffTreeItem], IO Bool)
 diffTree src dst = getdiff (Param "diff-tree")
-	[Param (fromRef src), Param (fromRef dst)]
+	[Param (fromRef src), Param (fromRef dst), Param "--"]
 
 {- Diffs two tree Refs, recursing into sub-trees -}
 diffTreeRecursive :: Ref -> Ref -> Repo -> IO ([DiffTreeItem], IO Bool)
 diffTreeRecursive src dst = getdiff (Param "diff-tree")
-	[Param "-r", Param (fromRef src), Param (fromRef dst)]
+	[Param "-r", Param (fromRef src), Param (fromRef dst), Param "--"]
 
 {- Diffs between a tree and the index. Does nothing if there is not yet a
  - commit in the repository. -}

Git/UnionMerge.hs

@@ -51,12 +51,12 @@ mergeIndex h repo bs = forM_ bs $ \b ->
 
 {- For merging two trees. -}
 mergeTrees :: Ref -> Ref -> CatFileHandle -> Repo -> Streamer
-mergeTrees (Ref x) (Ref y) h = doMerge h $ "diff-tree":diffOpts ++ [x, y]
+mergeTrees (Ref x) (Ref y) h = doMerge h $ "diff-tree":diffOpts ++ [x, y, "--"]
 
 {- For merging a single tree into the index. -}
 mergeTreeIndex :: Ref -> CatFileHandle -> Repo -> Streamer
-mergeTreeIndex (Ref x) h = doMerge h $
-	"diff-index" : diffOpts ++ ["--cached", x]
+mergeTreeIndex (Ref r) h = doMerge h $
+	"diff-index" : diffOpts ++ ["--cached", r, "--"]
 
 diffOpts :: [String]
 diffOpts = ["--raw", "-z", "-r", "--no-renames", "-l0"]

Logs/Activity.hs

@@ -26,7 +26,7 @@ recordActivity :: Activity -> UUID -> Annex ()
 recordActivity act uuid = do
 	ts <- liftIO getPOSIXTime
 	Annex.Branch.change activityLog $
-		showLog id . changeLog ts uuid (show act) . parseLog readish
+		showLog show . changeLog ts uuid act . parseLog readish
 
 lastActivities :: Maybe Activity -> Annex (Log Activity)
 lastActivities wantact = parseLog onlywanted <$> Annex.Branch.get activityLog

Utility/Url.hs

@@ -208,8 +208,7 @@ download' :: Bool -> URLString -> FilePath -> UrlOptions -> IO Bool
 download' quiet url file uo = do
 	case parseURIRelaxed url of
 		Just u
-			| uriScheme u == "file:" -> do
-				curl
+			| uriScheme u == "file:" -> curl
 			| otherwise -> ifM (inPath "wget") (wget , curl)
 		_ -> return False
   where

debian/changelog

@@ -1,11 +1,37 @@
-git-annex (5.20150406.2) UNRELEASED; urgency=medium
+git-annex (5.20150410) UNRELEASED; urgency=medium
 
+  * Fix activity log parsing, which caused the log to not retain
+    activity from other uuids.
+  * Union merge could fall over if there was a file in the repository
+    with the same name as a git ref. Now fixed.
+
+ -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 20:59:43 -0400
+
+git-annex (5.20150409) unstable; urgency=medium
+
+  * This fixes a bug in the assistant introduced by the literal pathspec
+    changes in version 5.20150406.
   * --quiet now suppresses progress displays from eg, rsync.
     (Second time's the charm..)
   * fromkey, registerurl: When reading from stdin, allow the
     filename and url, respectively, to contain whitespace.
+  * add: If annex.largefiles is set and does not match a file that's being
+    added, the file will be checked into git rather than being added to the
+    annex. Previously, git annex add skipped over such files; this new
+    behavior is more useful in direct mode.
+  * proxy: Made it work when run in a new repository before initial
+    commit.
+  * info: Display repository mode: bare when in a bare (non-direct mode)
+    repo.
+  * importfeed: Fix feed download when curl is used.
+  * importfeed: Error out when passed a non-url.
+  * webapp: When adding another local repository, and combining it
+    with the current repository, the new repository's remote path
+    was set to "." rather than the path to the current repository.
+    This was a reversion caused by the relative path changes in 5.20150113.
+  * contentlocationn: New plumbing command.
 
- -- Joey Hess <id@joeyh.name>  Mon, 06 Apr 2015 20:14:20 -0400
+ -- Joey Hess <id@joeyh.name>  Thu, 09 Apr 2015 15:06:38 -0400
 
 git-annex (5.20150406.1) unstable; urgency=medium
 

doc/bugs/commitBuffer:_invalid_argument___40__invalid_character__41__/comment_1_b56c847c5eda432a4330b4d853a25519._comment

@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:49:57Z"
+ content="""
+I cannot reproduce this, I get:
+
+	addurl _dev_radio/DR14__Verschwörungstheorien.ogg ok
+
+Does the _dev_radio/DR14__Verschwörungstheorien.ogg file get created?
+If so, how does it look?
+
+The jlog tells me it's trying to commit the git-annex branch journal.
+Does .git/annex/journal/ contain any files? Any files containing German
+characters?
+
+Do you have any git config settings for git-annex beyone the typical
+annex.uuid?
+
+I noticed one place in the journal commit code where it does seem to
+neglect to use filesystem encoding when dealing with writing filenames to
+the jlog tmpfile. Which could lead to this crash theoretically. I've fixed
+that, but since I couldn't reproduce the problem, I don't know if this will
+fix your problem. Nor do I understand how annex journal log files could
+have these characters in their names. You can try today's upcoming release
+of git-annex to test the fix though.
+"""]]

doc/bugs/corrupt_backend_upon_sync__63__.mdwn

@@ -0,0 +1,76 @@
+### Please describe the problem.
+
+When syncing with a remote, I get some files with "unknown backend".
+
+Original:
+
+    $ ls -lh Pictures/2014/06/21/2014-06-21\ 13.52.34.png
+    lrwxrwxrwx 1 jean jean 214 Jun 21  2014 Pictures/2014/06/21/2014-06-21 13.52.34.png -> ../../../../.git/annex/objects/mx/Ff/SHA256E-s247069--d425c1049778880eb9b9fcab74a82ec86dd22882db9c026f8fc0e9cb6270d022.34.png/SHA256E-s247069--d425c1049778880eb9b9fcab74a82ec86dd22882db9c026f8fc0e9cb6270d022.34.png
+
+This picture and symlink is fine.
+
+Remote (broken symlink):
+
+    $ ls -lh Pictures/2014/06/21/2014-06-21\ 13.52.34.png
+    lrwxrwxrwx 1 jean jean 214 Apr  6 12:50 Pictures/2014/06/21/2014-06-21 13.52.34.png -> ./../../.git/annex/objects/mx/Ff/SHA256E-s247069--d425c134ac2f9b0eb9b9fcab74a82ec86dd22882db9c026f8fc0e9cb6270d022.34.pn0.png/SHE-s247069--d425c1049778880eb9b9fcab74a82ec86dd22882db9c09efe84ca9cb6270d022.34.png
+
+In this case the paths differ: there is an extra `.pn0` component, and the final `SHA256E` has changed to `SHE`.
+
+### What steps will reproduce the problem?
+
+I don't know yet.
+
+### What version of git-annex are you using? On what operating system?
+
+    $ git annex version
+    git-annex version: 5.20140412ubuntu1
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+Ubuntu 14.04.1 LTS
+
+### Please provide any additional information below.
+
+[[!format sh """
+# If you can, paste a complete transcript of the problem occurring here.
+# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log
+
+$ git annex info
+repository mode: indirect
+trusted repositories: 0
+semitrusted repositories: 6
+        00000000-0000-0000-0000-000000000001 -- web
+        ...
+untrusted repositories: 0
+transfers in progress: none
+available local disk space: 168.35 gigabytes (+1 megabyte reserved)
+local annex keys: 16503
+local annex size: 39.15 gigabytes
+annexed files in working tree:
+  skipping Pictures/2014/06/21/2014-06-21 13.52.34.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.52.45.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.58.03.png (unknown backend SHA256EE)
+104552
+size of annexed files in working tree: 124.64 gigabytes
+bloom filter size: 16 mebibytes (3.3% full)
+backend usage:
+        SHA256E: 121054
+        SHA256: 1
+
+$ git annex get --from=laptop
+
+  skipping Pictures/2014/06/21/2014-06-21 13.52.34.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.52.45.png (unknown backend SHE)
+
+  skipping Pictures/2014/06/21/2014-06-21 13.58.03.png (unknown backend SHA256EE)
+
+
+# End of transcript or log.
+"""]]

doc/bugs/corrupt_backend_upon_sync__63__/comment_1_9f248d82f93040b739b56515d18458c7._comment

@@ -0,0 +1,24 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:39:28Z"
+ content="""
+The symink that you're showing is a file checked into git.
+
+So, you should be able to run `git log 'Pictures/2014/06/21/2014-06-21 13.52.34.png'`
+on the remote and find a commit that somehow changed the symlink to the
+broken one that the remote has.
+
+The only other possibilities are
+
+* Somehow the data in git in the remote got corrupted, and git didn't
+  notice. Seems very unlikely.
+* Somehow git decided to munge up the symlink when checking it out on the
+  remote. While there are some git features like smudge filters that could
+  perhaps be configured to do that, I don't see how git could do it on its
+  own.
+
+I've never seen git do anything like this.
+You're going to have to investigate this on your own and/or provide enough
+information to reproduce the problem.
+"""]]

doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load.mdwn

@@ -2,3 +2,4 @@
 
 Current layout is DIRHASH (of two levels) /KEY/KEY, so I would need to hardcode having that KEY directory.  It might be nice to either make DIRHASH to return full hash directory (but it might break existing special remotes), or supplement with e.g. DIRHASHFULL which would return all the levels necessary to reach the KEY file
 
+> [[done]] --[[Joey]]

doc/bugs/for_custom_remotes_provide_enhanced_DIRHASH_which_outputs_full_DIRHASH_to_the_key_load/comment_3_6430c915dd2969bda4070fa4ba01a935._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T19:08:40Z"
+ content="""
+I've added a contentlocation command
+
+I'd expect an external command to not be much slower than using the pipe
+for this. It does not need to spin up any git commands etc to get the
+content location. Also, you can pass it multiple keys to query at one time
+if necessary.
+
+I guess we'll see if this is too slow and can revisit it if so..
+"""]]

doc/bugs/git-annex-shell/comment_1_3d2c3827de34509c0a5595eda07dd18f._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T17:48:20Z"
+ content="""
+GIT_SSH is set to the full path of the binary, unless
+~/.config/git-annex/program overrides it.
+
+Finding the full path to the binary is not a trivial or error-free
+operation.
+
+Could you please follow up to this bug or close it?
+"""]]

doc/bugs/git-annex_unused_--from_s3_doesn__39__t.mdwn

@@ -0,0 +1,29 @@
+### Please describe the problem.
+
+The command `git annex unused --from mys3remote` shows no unused data, when I'm expecting at least one old version of a file in the current directory.
+
+### What steps will reproduce the problem?
+
+- Create a file, `git annex add` the file, sync with remotes and copy to an amazon S3 special remote
+- Run `git annex unlock` on the file, modify it, `git annex add` the file, sync and copy to S3
+- Now if you run `git annex unused` you should see the old version of the file in the local repo
+- But `git annex unused --from mys3remote` shows nothing
+- And I know that the old version is on S3 (at least according to the logs) because `git annex whereis --unused` shows that the file is both [here] and [mys3remote]
+
+I also noticed that the `git annex whereis --unused` command would show nothing if it was run directly after `git annex unused --from mys3remote`, but it would correctly show the locations when run directly after `git annex unused`.
+
+### What version of git-annex are you using? On what operating system?
+
+    git-annex version: 5.20141105-g8b19598
+    build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA CryptoHash
+    key/value backends: SHA256E SHA1E SHA512E SHA224E SHA384E SKEIN256E SKEIN512E SHA256 SHA1 SHA512 SHA224 SHA384 SKEIN256 SKEIN512 WORM URL
+    remote types: git gcrypt S3 bup directory rsync web webdav tahoe glacier ddar hook external
+    local repository version: 5
+    supported repository version: 5
+    upgrade supported from repository versions: 0 1 2 4
+
+arch linux x86_64
+
+### Please provide any additional information below.
+
+The S3 remote is encrypted with the default "hybrid" method

doc/bugs/git-annex_unused_--from_s3_doesn__39__t/comment_1_f139f18762f3acf8bfb9ce8a245b79f5._comment

@@ -0,0 +1,18 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:06:34Z"
+ content="""
+I have tried to reproduce this, and I can't seem to.
+
+There's no network traffic involved in git-annex unused --from remote,
+so I don't see how this can involve the S3 backend at all. If there's a bug
+here, it should affect any kind of remote.
+
+Are you sure you didn't forget to `git annex sync` before `git annex unused --from remote`?
+If you have an old synced/master branch, that'll count as a user of the
+file and so unused won't show it.
+
+I think you'll need to provide a full transcript of how to make this problem
+happen for me to get any further.
+"""]]

doc/bugs/importfeed_fails_with_local_file_urls.mdwn

@@ -26,3 +26,10 @@ Is it possible to use local files in rss format with items which reference local
 
 Cheers,
 Marco
+
+> I've fixed it with file:// urls. 
+>
+> Also made it error out on non-url feed inputs, which are not intended to be
+> supported.
+>
+> [[done]] --[[Joey]]

doc/bugs/pathspec_magic_not_supported_by_this_command:___39__literal__39__.mdwn

@@ -0,0 +1,104 @@
+### Please describe the problem.
+
+I have some paths containing swedish characters (åäö ÅÄÖ).
+Some paths also contains the character "@".
+I use git annex assistant in autostart mode on my Documents folder.
+
+I get the following errors in the log file:
+
+[[!format sh """
+fd:37: commitBuffer: invalid argument (invalid character)
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr<47><72><EFBFBD><EFBFBD><EFBFBD><EFBFBD>nsytem<65><6D><EFBFBD><EFBFBD><EFBFBD><EFBFBD>te/MMD_Config/SITE/LegacyNT/mmd/config/Dataintag/Fil-intag/OLDIB/SurfaceWaterTemperature.ini: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal'
+fatal: Work/@Projects/archive/20140515_METOCC_Gr: pathspec magic not supported by this command: 'literal''
+"""]]
+
+I also notice a lot of zombie git processes in the ps list.
+
+### What steps will reproduce the problem?
+
+Upgrade to Version: 5.20150406-gb2814bc
+Build flags: Assistant Webapp Webapp-secure Pairing Testsuite S3 WebDAV Inotify DBus DesktopNotify XMPP DNS Feeds Quvi TDFA 
+
+Pre compiled tar.gz 
+
+### What version of git-annex are you using? On what operating system?
+
+Version: 5.20150406-gb2814bc
+
+Arch linux
+
+[daniel@wintermute Documents]$ uname -a
+Linux wintermute 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux
+
+
+### Please provide any additional information below.
+
+If I downgrade to a previous version ie. git-annex.linux.5.20150317 the described problem is gone.
+
+I tried to remove the character "@" from my paths, but it didn't help.
+
+Looking at the log file below, it doesn't seem to have anything to do with my swedish characters. 
+
+
+[[!format sh """
+[2015-04-07 22:24:14 CEST] main: starting assistant version 5.20150406-gb2814bc
+[2015-04-07 22:24:14 CEST] TransferScanner: Syncing with xxxxxxx.xxxxxxx.xxx_wintermute_Documents 
+p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-trust.so: cannot open shared object file: No such file or directory
+(scanning...) [2015-04-07 22:24:15 CEST] Watcher: Performing startup scan
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/firewall-udp-1194-dasu-Viscosity.visc.zip: pathspec magic not supported by this command: 'literal'
+
+git cat-file EOF: user error
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+fatal: Work/archive/Tidrapportering/Tid.md: pathspec magic not supported by this command: 'literal'
+
+"""]]
+
+> I've fixed the pathspec magic problem. [[done]]
+> 
+> Seems like you could possibly have a separate problem WRT the "commitBuffer:
+> invalid argument". When using the older version of git-annex, did you 
+> get that in the log at all?
+>
+> OTOH, the
+> "@Projects/archive/20140515_METOCC_Gr������nsytem������te" 
+> weirdness in the log could be where the problem chars are coming from
+> too, in which case it was somehow caused by the pathspec magic problem.
+> 
+> I was able to reproduce the pathspec magic problem, but not the encoding
+> looking problem, even when using swedish chars in filenames.
+> 
+> --[[Joey]]
+
+>> I tried an older version of git-annex on the same repository, and could not find any "commitBuffer:
+>> invalid argument" in the log.
+>>
+>> I would like to take the chance to thank you for the incredible work you are doing with this software/tool! It's an amazing effort!
+>>
+>> -Daniel
+

doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter.mdwn

@@ -0,0 +1,12 @@
+### Please describe the problem.
+When git-annex is started using one of its start menu shortcuts (git-annex or git-annex-autostart) wscript.exe calls itself in an infinite loop. This is also described under the [section ".vbs failure" in a forum post](https://git-annex.branchable.com/forum/Windows_installation_notes/).
+
+### What steps will reproduce the problem?
+Install git and git-annex according to the [installation guide](https://git-annex.branchable.com/install/Windows/). Click on one of the shortcuts in the start menu.
+
+### What version of git-annex are you using? On what operating system?
+git version 1.9.5.msysgit.1. git-annex version: 5.20150317-g237d5b0. Windows 7 Professional, 64-bit.
+
+### Please provide any additional information below.
+
+This seems to be fixed by editing the shortcuts and setting the "Start in" parameter to the git installation directory. For me this is "C:\Program Files (x86)\Git".

doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_1_5af705ddb453588711f3e70b2e297f55._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:15:31Z"
+ content="""
+Thanks for reporting this.
+
+Is git in your path? (Ie, can you run git from command.exe?)
+
+I notice that the
+<http://git-annex.branchable.com/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/>
+page, which had this problem, was a user who neglected to have git add
+itself to path, contrary to what the installation instructiins say to do.
+
+So, it's not surprising that disregarding the instructions break, but this
+is a bad way for it to break. It would be better to at least avoid the
+loop, and perhaps Just Work.
+
+I don't understand why it loops.. the git-annex-webapp.vbs runs "git-annex
+webapp". If git-annex is not in path (because git is not in path and it
+piggybacks off git's path settings), that should fail to do anything. 
+Or is Windows really sufficiently DWIM that it will search for **different
+spellings** of program names?!
+
+I don't see how I can add a "Start in" parameter; git-annex has no way of
+knowing where the user intended to install git if they didn't add git to
+the path.
+"""]]

doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_2_f68896dee17aa663749912e663f10a9f._comment

@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://launchpad.net/~eliasson"
+ nickname="eliasson"
+ subject="comment 2"
+ date="2015-04-09T20:43:08Z"
+ content="""
+Yes, Git is in my path. This is my full (system, not user) path, copied from System Properties->Advanced->Environment Variables:
+
+    C:\ProgramData\Oracle\Java\javapath;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\QuickTime\QTSystem\;C:\Program Files (x86)\Git\cmd
+
+I've done some more experimentation now. I believe that in Windows the current working directory is always first in the path. I also think that \"Start in\" sets the CWD of a shortcut and if unset, its CWD is its location in the Start menu. The shortcut is named git-annex.lnk and executes a VBscript that runs \"git-annex webapp\". This is probably why the shortcut executes itself.
+
+Setting the Start in parameter to anything (doesn't have to be Git's installation directory) *or* renaming the shortcut to something other than git-annex makes it work. A third way of fixing it is to open git-annex-webapp.vbs and changing \"git-annex webapp\" to \"git annex webapp\". I don't know which option is the cleanest solution.
+
+I take it back that git-annex-autostart loops. I seem to remember that it did on another computer (running a version of git-annex downloaded today) but probably remember wrong. Now I can only reproduce this with the webapp shortcut.
+
+"""]]

doc/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/comment_3_6c3e6b1344c533857611c0f6033c0dce._comment

@@ -0,0 +1,25 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T20:53:17Z"
+ content="""
+I'm guessing this doesn't affect XP, so I'm going to need to rely on you
+guys for help and testing for the newer Windows..
+
+Makes sense about git-annex.lnk trying to run itself, I suppose. Sort of.
+
+The DSL I'm using to generate the NSIS installer and thus this file
+doesn't currently seem to have a way to set the "Start in" parameter.
+I can get that added, but it would take a while.
+
+I don't see any reason not to use the "git annex webapp" approach.
+Should be the same as long as git's in path, and if git's not in path,
+well.
+
+Alternatively, though, I could rename the menu item to something else, like
+"git-annex-menu.lnk". Seems that would also avoid the problem, and somewhat
+more robustly. I don't like this business of conflicting command-names
+being in path. Renaming the menu item has the downside of needing a
+uninstall/reinstall cycle to avoid getting a duplicate menu item, but
+otherwise seems reasonable.
+"""]]

doc/design/metadata/comment_11_402d7d3e8e7f2df57eb6685134226642._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 11"""
+ date="2015-04-09T18:31:34Z"
+ content="""
+@Sunke, the reason that views make up their own filenames is to
+avoid the problem of having 2 files in a view that have the same
+name.
+
+In your example, that could happen if you used --set title
+with the same title for 2 separate files.
+
+So, I don't think this can be supported reasonably.
+"""]]

doc/devblog/day_273__unexpected_release.mdwn

@@ -0,0 +1,15 @@
+I've had to release git-annex twice this week to fix reversions. On Monday,
+just after I made a planned release, I discovered a bug in it, and had to
+update it with a .1 release. Today's release fixes 2 other reversions
+introduced by recent changes, both only affecting the assistant.
+
+Before making today's release, I did a bunch of other minor bugfixes and
+improvements, including adding a new `contentlocationn` plumbing command.
+This release also changes `git annex add` when annex.largefiles is
+configured, so it will `git add` the non-large files. That is particularly
+useful in direct mode.
+
+I feel that the assistant needs some TLC, so I might devote a week to it in
+the latter part of this month. My current funding doesn't cover work
+on the assistant, but I should have some spare time toward the end of the
+month.

doc/forum/Adding_a_mounted_network.mdwn

@@ -0,0 +1 @@
+I would like to add (bare) repositories on network directories that are locally mounted. "Add more repositories" gives me many choices, which apparently does not include this specifically. It does have "Removable drive" which sees the CIFS directory (perhaps because it's under /media?) but not the AFS directory, and there doesn't seem to be a way to enter a path where it's not inclined to look ("rescan for removable drives" still misses /afs). I am comfortable using shell commands, but I don't know what commands to use.

doc/forum/Adding_a_mounted_network/comment_1_9b4bab6177856569adfec26ada6b01cd._comment

@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"
+ nickname="Justin"
+ subject="comment 1"
+ date="2015-04-09T13:17:41Z"
+ content="""
+It's just a git remote..
+
+    git remote add somerepo /path/to/repo
+    git annex sync
+
+should be all you need.
+"""]]

doc/forum/Adding_a_mounted_network/comment_2_ae3d4ac918ef002ead859ed0c962ae32._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2015-04-09T18:33:47Z"
+ content="""
+If you want to do with using the webapp, go to the "Repository"
+menu in the upper-left, and select "Add another local repository."
+
+You can then enter the path to your repository, whevever it is, 
+and click on "combine the repositories"
+
+But, like Justin said, this just sets up a git remote, so doing it at
+the command line will work just as well.
+"""]]

doc/forum/Newb_question_on_sneekernet_sync.mdwn

@@ -0,0 +1,7 @@
+Hi,
+
+I have set up git-annex to sync a folder located on laptop A, USB Key, and laptop B.   After reading the walkthrough, I don't quite understand the proper procedure to keep in sync.  Should I run git-annex sync from within the sync directory on the USB Key on laptop A and then from within the sync folder on the USB Key when plugged into laptop B?  Or do I have to run git-annex sync from within the sync directory on the laptops, then the USB Key?  And/or do I have to run git-annex get on the sync directory on the USB key before syncing to the second laptop?
+
+Also I should not normally be making changes on laptops A and B at the same time, but if that were the case, is there any difference in what I would run to sync the changes?
+
+Thanks!

doc/forum/Newb_question_on_sneekernet_sync/comment_1_409cc5ba605d63331b386066d32f797b._comment

@@ -0,0 +1,31 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E"
+ nickname="Сергей"
+ subject="comment 1"
+ date="2015-04-08T12:31:33Z"
+ content="""
+Well, working with git annex, you should think of two things:
+
+1. location of annex information (git commit tree), let's call it INFO
+2. location of files contents, let's call it CONTENT
+
+So, for your sneekernet scenario these general steps are required:
+
+1. sync INFO between Laptop A and USB
+2. transfer required CONTENT from LAPTOP A to USB
+3. sync INFO between Laptop B and USB
+4. transfer required CONTENT from USB to Laptop B
+
+Let's describe your options on every step:
+
+1. issue `git annex sync` on Laptop A. Either from within USB or Laptop repo, I prefer Laptop because of automatic commit.
+2. 
+   * issue `git annex copy <files> --to=<usb-remote-name>` from within Laptop A repo
+   * issue `git annex get <files>` from within USB repo. This is not possible if you have bare repo on USB.
+3. issue `git annex sync` on Laptop B
+4. same as 2, but transfer to Laptop B
+
+Also, using `git annex sync --content`, you don't need to manually transfer CONTENT, see [--content](https://git-annex.branchable.com/git-annex-sync/). But in this case you somewhat loose control of what is transferred.
+
+If you make changes on both laptops at the same time no extra steps required. In case of conflict both versions saved in working directory, see [automatic conflict resolution](http://git-annex.branchable.com/automatic_conflict_resolution/).
+"""]]

doc/forum/Slow_transfer_speeds_on_copy_in_Windows.mdwn

@@ -0,0 +1,3 @@
+Copying a large file from windows (msysgit 1.9.5.msysgit.1, git-annex 20150406) to a bare repository on debian wheezy (git 1.9.1 git-annex 20141024)  I can only get around 2 MB/s transfer speed.  I tested using normal windows copy (smb) and got around 10 MB/s, while the git-annex copy was still going on.  I tried plain ssh and got 9 MB/s.  So, something to do with git-annex is being slow it seems.  Any ideas on how to remedy this, or is it a known issue?
+
+Note: Problem not seen going from linux to linux... waaaayyy faster (40 MB/s) to put it lightly (10 min vs all day)  The destination server is the same.

doc/forum/Slow_transfer_speeds_on_copy_in_Windows/comment_1_dd4ebb10ac87e3ee6158b7e7b1273a81._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T20:30:19Z"
+ content="""
+There's not a lot of places where git-annex could make this slower.
+git-annex copy is just running rsync to the ssh server.
+
+Have you tried benchmarking rsync of a large file to the server w/o
+git-annex? rsync does do considerably more client-side work than does
+scp, in order to support resuming, so that might be it.
+"""]]

doc/forum/Using_git-annex_to_manage_git_repositories/comment_3_5cf9e2ff83bb76650469444c80fee4fb._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawk_STgv_0fB-y1x_fgzUI10Bg-aajJyMyc"
+ nickname="猫"
+ subject="comment 3"
+ date="2015-04-08T06:30:06Z"
+ content="""
+I'll take a closer look at myrepos, but it doesn't seem to do location tracking, which is the main feature of git-annex that I'm looking for.
+"""]]

doc/forum/Why_are_ignored_files_being_deleted__63__.mdwn

@@ -0,0 +1,22 @@
+How do we get into the following situation?
+First we complain about an ignored file (why not just ignore it?),
+and then apparently we delete the ignored file.
+
+    [...]
+    import Pictures/2005/11/16/.IMG_0819.tmpwrite.JPG (duplicate) ok
+    (Recording state in git...)
+    The following paths are ignored by one of your .gitignore files:
+    Pictures/2008/11/27/.img_1315.tmpwrite.jpg
+    Use -f if you really want to add them.
+    fatal: no files added
+    git-annex: user error (xargs ["-0","git","--git-dir=/.../annex/.git","--work-tree=/.../annex","add","--"] exited 123)
+
+    # eek, the file that we complained about has vanished!
+    $ rm ../Pictures/2008/12/27/.img_1315.tmpwrite.jpg
+    rm: cannot remove ‘../Pictures/2008/11/27/.img_1315.tmpwrite.jpg’: No such file or directory
+
+Expected:
+- leave ignored files untouched. Maybe report "Skipped ignored files."
+
+Actual:
+- Stop import, but delete the ignored file as side effect.

doc/forum/Why_are_ignored_files_being_deleted__63__/comment_1_3081bda5bb600fc564185499ddfb5cf9._comment

@@ -0,0 +1,35 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="Ignored file imported, in spite of error message"
+ date="2015-04-08T09:08:53Z"
+ content="""
+Today I'm seeing this:
+
+    git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/.../annex/.git\",\"--work-tree=/.../annex\",\"add\",\"--\"] exited 123)
+    failed
+    (Recording state in git...)
+    The following paths are ignored by one of your .gitignore files:
+    btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp
+    Use -f if you really want to add them.
+    fatal: no files added
+
+    git-annex: user error (xargs [\"-0\",\"git\",\"--git-dir=/.../annex/.git\",\"--work-tree=/.../annex\",\"add\",\"--\"] exited 123)
+    failed
+    (Recording state in git...)
+    ^C
+
+This repeats until I kill the import.
+
+Subsequently I see that the ignored file was in fact imported:
+
+    $ ls -lh \"btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp\"
+    lrwxrwxrwx 1 user user 203 Jan 11 14:11 btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp -> ../../../.git/annex/objects/0K/GX/SHA256E-s0--e3b0c44298ec1c149aebe4c8996eb92427ae41e4649b934ca495991b7852b855.jpg.tmp/SHA256E-s0--e3b0c44298ec1c149aebe4c8996eb92427ae41e4649b934ca495991b7852b855.jpg.tmp
+
+In this case the original file was not deleted, because I used `import --duplicate`:
+
+    $ ls -lh \"../btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp\"
+    -rw-rw-r-- 1 user user 0 Jan 11 14:11 ../btsync/DCIM (1)/Camera 1/20150101090842.jpg.tmp
+
+
+"""]]

doc/forum/Why_are_we_stopping_at_a_duplicate__63__.mdwn

@@ -0,0 +1,7 @@
+What does the following mean? I would expect that if we encounter a duplicate while using the `--deduplicate` option, the duplicate file would be removed from the import location and import would continue. Does that mean that the newly encountered `img_0405.jpg` is different from the one previously seen? 
+Could the error message perhaps be improved?
+
+    .../usbdisk/annex(master)$ git annex import --deduplicate ../Pictures/
+    import Pictures/2008/10/12/img_0405.jpg git-annex: not overwriting existing Pictures/2008/10/12/img_0405.jpg (use --force to override)
+
+Many other duplicates are being tidied away.

doc/forum/Why_is_git_annex_status_slow__63__/comment_2_2f61c2cdf9d1ffd298fd906207012818._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkutSE8_3fFAETmO_E598zja4gKwYXbb8E"
+ nickname="Сергей"
+ subject="Slow on windows but not on linux"
+ date="2015-04-07T18:20:23Z"
+ content="""
+If this is by design and `git annex status` should take more time in direct mode then what I'm experiencing is strange. On windows every 100M file adds approximately 1 second to `status` duration (on my laptop), but on linux it does not. On linux `git annex status` even in direct mode takes milliseconds. What is wrong with my setup?
+"""]]

doc/forum/Why_is_git_annex_status_slow__63__/comment_3_8d9e5a1aef2648d7a844623e6237d551._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 3"""
+ date="2015-04-09T17:44:01Z"
+ content="""
+The sizes of the files should not affect how fast git-annex status runs. 
+
+But, direct mode certianly does. git-annex has to do significantly more
+work in direct mode to figure out the status of a file. Including querying
+git. In indirect mode, it can just stat the symlink and see if its content
+is present, which is much faster.
+
+(There's probably also some other inneficiencies in Windows.)
+"""]]

doc/forum/Windows_installation_notes/comment_1_54c253ab61fea4f5aaefa04bb078c7b0._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2015-04-09T18:26:30Z"
+ content="""
+Not following the instructions to have git put itself into the path seems
+like a sure-fire way to shoot yourself in the foot.
+
+The loop problem is being discussed at
+<http://git-annex.branchable.com/bugs/windows_start_menu_shortcuts_are_missing___34__Start_in__34___parameter/>
+perhaps you'll be able to answer my questions about it there?
+"""]]

doc/forum/Windows_installation_notes/comment_2_c8c2744e30f2950d9830936d2bd51617._comment

@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkQOUUx4LVAk6EnstSLvdv7gZc0NsRlHXw"
+ nickname="Dave"
+ subject="comment 2"
+ date="2015-04-09T20:37:51Z"
+ content="""
+Sorry, joey, I haven't played with git annex on windows since my original post.
+
+I only have one new piece of information: some git annex related auto-start entry was added to the user profile of the account I used to perform the installation.  I noticed this when I logged in interactively as that user...
+
+See what I'm saying?  I have DOMAIN\dave.loyall and WORKSTATION\local.admin.  I have to use the latter to carry out installation, via \"Run as...\", but I need stuff to be installed into DOMAIN\dave.loyall's profile or the AllUsers profile (or whatever it is called).
+
+Meanwhile, more and more of my daily work is carried out in my GNU/Linux virtual machines.  I don't personally want/need anyone to prioritize windows-only deficiencies.
+"""]]

doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__.mdwn

@@ -0,0 +1,32 @@
+We have the correct symlink:
+
+    $ ls -lh Sita_Sings_the_Blues_480p_2150kbps.mp4 
+    lrwxrwxrwx 1 user user 204 Apr  8 20:22 Sita_Sings_the_Blues_480p_2150kbps.mp4 -> .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+
+The object is in place:
+
+    $ ls -lh .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+    -r-------- 1 user user 1,4G Dec 28  2010 .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+
+Now I move the symlink, which becomes broken:
+
+    $ mv Sita_Sings_the_Blues_480p_2150kbps.mp4 Videos/
+
+I try to fix the symlink:
+
+    $ git annex sync
+    $ git annex fix Videos/Sita_Sings_the_Blues_480p_2150kbps.mp4 
+
+But it stays broken:
+
+    $ ls -lh Videos/Sita_Sings_the_Blues_480p_2150kbps.mp4 
+    lrwxrwxrwx 1 user user 204 Apr  8 20:22 Videos/Sita_Sings_the_Blues_480p_2150kbps.mp4 -> .git/annex/objects/6q/Wz/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4/SHA256E-s1463013630--2a18a317a536d8e2d28e7916a45a007679b7192102a71067de488c9faa6aab45.mp4
+
+Ah, when I try to `git mv Sita_Sings_the_Blues_480p_2150kbps.mp4 Videos/`, 
+I am warned that the link is not under version control. How did the symlink get 
+made in the first place, if not by git-annex? It should be known, right?
+
+After I `git annex add`, I can `git mv` and then `git annex fix`.
+
+How did I get into the state where I have a symlink pointing at an imported
+object, which is not under version control?

doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_1_865245182d765fed7bbeb42a35dd605e._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 1"
+ date="2015-04-08T14:29:59Z"
+ content="""
+'git annex fix' will only fix symlinks that git is tracking (either staged, or part of the repository) because git-annex uses git-ls-files (or something like that) to get the filenames to fix.
+
+'git annex add' adds the files to the annex and replaces them with symlinks, stages the symlinks but does not commit the symlinks.
+"""]]

doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_2_c1f5a285b7cfb92d218b9b0d31caeed6._comment

@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="CandyAngel"
+ subject="comment 2"
+ date="2015-04-08T14:32:56Z"
+ content="""
+It's also funny that this has cropped up [just after I asked for git-annex to fix untracked symlinks](https://git-annex.branchable.com/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/) :P
+"""]]

doc/forum/why_doesn__39__t___96__git_annex_fix__96___fix_a_link__63__/comment_3_be2816c47091842b829cd626e18c5fda._comment

@@ -0,0 +1,9 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="comment 3"
+ date="2015-04-09T05:37:03Z"
+ content="""
+Hi CandyAngel, thanks for the pointer, I 
+[commented](http://git-annex.branchable.com/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/#comment-5251d819e83c66dbdd9d7bcee4a87f9f) there.
+"""]]

doc/git-annex-add.mdwn

@@ -14,6 +14,10 @@ files from the current directory and below.
 Normally, files that are already checked into git, or that git has been
 configured to ignore will be silently skipped.
 
+If annex.largefiles is configured, and does not match a file that is being
+added, `git annex add` will behave the same as `git add` and add the
+non-large file directly to the git repository, instead of to the annex.
+
 # OPTIONS
 
 * `--include-dotfiles`

doc/git-annex-contentlocation.mdwn

@@ -0,0 +1,27 @@
+# NAME
+
+git-annex contentlocation - looks up content for a key
+
+# SYNOPSIS
+
+git annex contentlocation `[key ...]`
+
+# DESCRIPTION
+
+This plumbing-level command looks up filename used to store the content 
+of a key. The filename is output to stdout. If the key's content is not
+present in the local repository, nothing is output, and it exits nonzero.
+
+Note that in direct mode, the file will typically be in the git work
+tree, and while its content should correspond to the key, the file
+could become modified at any time after git-annex checks it.
+
+# SEE ALSO
+
+[[git-annex]](1)
+
+# AUTHOR
+
+Joey Hess <id@joeyh.name>
+
+Warning: Automatically converted into a man page by mdwn2man. Edit with care.

doc/git-annex.mdwn

@@ -513,6 +513,12 @@ subdirectories).
 
   See [[git-annex-lookupkey]](1) for details.
 
+* `contentlocation [key ..]`
+
+  Looks up location of annexed content for a key.
+
+  See [[git-annex-contentlocation]](1) for details.
+
 * `examinekey [key ...]`
 
   Print information that can be determined purely by looking at the key.

doc/news/version_5.20150219.mdwn

@@ -1,34 +0,0 @@
-git-annex 5.20150219 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
-   * glacier: Detect when the glacier command in PATH is the wrong one,
-     from boto, rather than from glacier-cli, and refuse to use it,
-     since the boto program fails to fail when passed
-     parameters it does not understand.
-   * groupwanted: New command to set the groupwanted preferred content
-     expression.
-   * import: Support file matching options such as --exclude, --include,
-     --smallerthan, --largerthan
-   * The file matching options are now only accepted by commands that
-     can actually use them, instead of by all commands.
-   * import: Avoid checksumming file twice when run in the default
-     or --duplicate mode.
-   * Windows: Fix bug in dropping an annexed file, which
-     caused a symlink to be staged that contained backslashes.
-   * webapp: Fix reversion in opening webapp when starting it manually
-     inside a repository.
-   * assistant: Improve sanity check for control characters when pairing.
-   * Improve race recovery code when committing to git-annex branch.
-   * addurl: Avoid crash if quvi is not installed, when git-annex was
-     built with process-1.2
-   * bittorrent: Fix mojibake introduced in parsing arai2c progress output.
-   * fsck --from: If a download from a remote fails, propagate the failure.
-   * metadata: When setting metadata, do not recurse into directories by
-     default, since that can be surprising behavior and difficult to recover
-     from. The old behavior is available by using --force.
-   * sync, assistant: Include repository name in head branch commit message.
-   * The ssh-options git config is now used by gcrypt, rsync, and ddar
-     special remotes that use ssh as a transport.
-   * sync, assistant: Use the ssh-options git config when doing git pull
-     and push.
-   * remotedaemon: Use the ssh-options git config.
-   * Linux standalone: Improved process names of linker shimmed programs."""]]

doc/news/version_5.20150409.mdwn

@@ -0,0 +1,23 @@
+git-annex 5.20150409 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+   * This fixes a bug in the assistant introduced by the literal pathspec
+     changes in version 5.20150406.
+   * --quiet now suppresses progress displays from eg, rsync.
+     (Second time's the charm..)
+   * fromkey, registerurl: When reading from stdin, allow the
+     filename and url, respectively, to contain whitespace.
+   * add: If annex.largefiles is set and does not match a file that's being
+     added, the file will be checked into git rather than being added to the
+     annex. Previously, git annex add skipped over such files; this new
+     behavior is more useful in direct mode.
+   * proxy: Made it work when run in a new repository before initial
+     commit.
+   * info: Display repository mode: bare when in a bare (non-direct mode)
+     repo.
+   * importfeed: Fix feed download when curl is used.
+   * importfeed: Error out when passed a non-url.
+   * webapp: When adding another local repository, and combining it
+     with the current repository, the new repository's remote path
+     was set to "." rather than the path to the current repository.
+     This was a reversion caused by the relative path changes in 5.20150113.
+   * contentlocationn: New plumbing command."""]]

doc/not.mdwn

@@ -37,9 +37,13 @@
   partial checkouts of file contents, like git-annex does.
 
 * git-annex is similarly not [git-fat](https://github.com/jedbrown/git-fat),
-  which also uses git smudge filters, and also lacks git-annex' widely
+  which also uses git smudge filters, and also lacks git-annex's widely
   distributed storage and partial checkouts.
 
+* Similarly, git-annex is not [git-lfs](https://github.com/github/git-lfs),
+  which also uses git smudge filters, and appears to lack git-annex's
+  widely distributed storage.
+
 * git-annex is also not [boar](http://code.google.com/p/boar/),
   although it shares many of its goals and characteristics. Boar implements
   its own version control system, rather than simply embracing and

doc/tips/downloading_podcasts.mdwn

@@ -48,6 +48,12 @@ Then you can run git-annex on all the feeds:
 
 `xargs git-annex importfeed < feeds`
 
+## recreating lost episodes
+
+If for some reason git-annex refuses to download files you are certain are in the podcast, it is quite possible it is because they have already been downloaded. In any case, you can use `--force` to redownload them:
+
+`git-annex importfeed --force http://example.com/feed`
+
 ## distributed podcatching
 
 A nice benefit of using git-annex as a podcatcher is that you can

doc/tips/publishing_your_files_to_the_public.mdwn

@@ -53,3 +53,11 @@ However, instead of just a list of links we will output a markdown-formatted lis
     end
 
 Very useful.
+
+## Sharing links with time-limited URLs
+
+By using pre-signed URLs it is possible to create limits on how long a URL is valid for retrieving an object. 
+To enable use a private S3 bucket for the remotes and then pre-sign actual URL with the script in [AWS-Tools](https://github.com/gdbtek/aws-tools).
+Example:
+
+    key=`git annex lookupkey "$fname"`;  sign_s3_url.bash --region 'eu-west-1' --bucket 'mybuck' --file-path $key --aws-access-key-id XX --aws-secret-access-key XX --method 'GET' --minute-expire 10

doc/todo/__34__git-annex_fix__34___on_untracked__44___but_git-annexy_symlinks/comment_4_1e10274827564902047c72a81affd92c._comment

@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnVnsqEy82M-MuS2gLri-az83wSQ6lXSrc"
+ nickname="Jean"
+ subject="I'm with Remy here"
+ date="2015-04-09T05:02:50Z"
+ content="""
+I can't even comprehend how git-annex gets into this situation. From what angle does it make sense to ever have a symlink pointing at a `.git/annex/objects/...` and not be tracked?
+"""]]

doc/todo/smudge.mdwn

@@ -94,11 +94,20 @@ and it slows down *everything*, from `git status` to `git commit`.
 this. <http://marc.info/?l=git&m=131465033512157&w=2> (Update: apparently
 can't be fixed.)
 
+> Update: I tried this again (2015) and it seems that git status and git
+> add avoid re-sending the file content to the clean filter, as long as the
+> file stat has not changed. I'm not sure when git started doing that,
+> but it seems to avoid this problem.
+> --[[Joey]]
+
 #### smudge
 
 The smudge script can also be provided a filename with %f, but it
 cannot directly write to the file or git gets unhappy.
 
+> Still the case in 2015. Means an unnecesary read and pipe of the file
+> even if the content is already locally available on disk. --[[Joey]]
+
 ### dealing with partial content availability
 
 The smudge filter cannot be allowed to fail, that leaves the tree and

git-annex.cabal

@@ -1,5 +1,5 @@
 Name: git-annex
-Version: 5.20150406.1
+Version: 5.20150409
 Cabal-Version: >= 1.8
 License: GPL-3
 Maintainer: Joey Hess <id@joeyh.name>