packages feed

git-annex 3.20121127 → 3.20121127.1

raw patch · 40 files changed

+26/−628 lines, 40 files

Files

Assistant/Install.hs view
@@ -21,7 +21,6 @@ import Utility.FreeDesktop #endif -import Data.AssocList import System.Posix.Env  standaloneAppBase :: IO (Maybe FilePath)@@ -84,9 +83,10 @@ 		| otherwise = Just $ catMaybes $ map (restoreorig env) env 		| otherwise = Nothing 	  where-		vars = words $ lookup1 "GIT_ANNEX_STANDLONE_ENV" env-		restoreorig oldenv p@(k, v)-			| k `elem` vars = case lookup1 ("ORIG_" ++ k) oldenv of-				"" -> Nothing-				v' -> Just (k, v')+		vars = words $ fromMaybe "" $+			lookup "GIT_ANNEX_STANDLONE_ENV" env+		restoreorig oldenv p@(k, _v)+			| k `elem` vars = case lookup ("ORIG_" ++ k) oldenv of+				Nothing -> Nothing+				(Just v') -> Just (k, v') 			| otherwise = Just p
CHANGELOG view
@@ -1,3 +1,9 @@+git-annex (3.20121127.1) UNRELEASED; urgency=low++  * Fix cabal build, avoiding module from hxt.++ -- Joey Hess <joeyh@debian.org>  Tue, 27 Nov 2012 22:57:39 -0400+ git-annex (3.20121127) unstable; urgency=low    * Fix dirContentsRecursive, which had missed some files in deeply nested
debian/changelog view
@@ -1,3 +1,9 @@+git-annex (3.20121127.1) UNRELEASED; urgency=low++  * Fix cabal build, avoiding module from hxt.++ -- Joey Hess <joeyh@debian.org>  Tue, 27 Nov 2012 22:57:39 -0400+ git-annex (3.20121127) unstable; urgency=low    * Fix dirContentsRecursive, which had missed some files in deeply nested
− doc/.git-annex.mdwn.swp

binary file changed (28672 → absent bytes)

− doc/bugs/3.20121113_build_error___39__not_in_scope_getAddBoxComR__39__.mdwn 
@@ -1,33 +0,0 @@-What steps will reproduce the problem?--Building from latest source, Cabal update, cabal install --only dependencies, cabal configure, Cabal build--What is the expected output? What do you see instead?--Error message from build--...--Loading package DAV-0.2 ... linking ... done.--Loading object (static) dist/build/git-annex/git-annex-tmp/Utility/libdiskfree.o ... done--Loading object (static) dist/build/git-annex/git-annex-tmp/Utility/libmounts.o ... done--final link ... done---Assistant/Threads/WebApp.hs:47:1: Not in scope: `getAddBoxComR'--Assistant/Threads/WebApp.hs:47:1: Not in scope: `getEnableWebDAVR'---What version of git-annex are you using? On what operating system?--Latest version via git from git-annex.branchable.com--Debian Squeeze (6.0.6)--Please provide any additional information below.--> I noticed this earlier and fixed it. [[done]] --[[Joey]]
− doc/bugs/Is_there_any_way_to_rate_limit_uploads_to_an_S3_backend__63__.mdwn 
@@ -1,19 +0,0 @@-What steps will reproduce the problem?--Adding files to a local annex set up to sync to a remote S3 one---What is the expected output? What do you see instead?--It syncs, but maxes out the uplink---What version of git-annex are you using? On what operating system?--3.20121112 on Debian testing---Please provide any additional information below.--The man page lists how to configure rate limiting for rsync, not sure how to do it for this-
doc/bugs/JSON_output_broken_with___34__git_annex_sync__34__.mdwn view
@@ -16,3 +16,6 @@ What version of git-annex are you using? On what operating system?  Newest standalone (3.20121126), Linux i386. The "json_reformat" program is from the "yajl-tools" .deb package.++> [[done]]; I've updated the --json documentation to note that it only+> works with some query commands. --[[Joey]]
− doc/bugs/Lost_S3_Remote/comment_1_6e80e6db6671581d471fc9a54181c04c._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-01-06T03:04:35Z"- content="""-Despite `status` listing S3 support, your git-annex is actually built with S3stub, probably because it failed to find the necessary S3 module at build time. Rebuild git-annex and watch closely, you'll see \"** building without S3 support\". Look above that for the error and fix it.--It was certianly a bug that it showed S3 as supported when built without it. I've fixed that.-"""]]
− doc/bugs/Lost_S3_Remote/comment_2_c99c65882a3924f4890e500f9492b442._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2012-01-06T03:08:28Z"- content="""-BTW, you'll want to \"make clean\", since the S3stub hack symlinks a file into place and it will continue building with S3stub even if you fix the problem until you clean.-"""]]
− doc/bugs/Lost_S3_Remote/comment_3_1e434d5a20a692cd9dc7f6f8f20f30dd._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkey8WuXUh_x5JC2c9_it1CYRnVTgdGu1M"- nickname="Dustin"- subject="Thank you!"- date="2012-01-06T03:38:27Z"- content="""-make clean and rebuild worked...  Thank you-"""]]
− doc/bugs/More_sync__39__ing_weirdness_with_the_assistant_branch_on_OSX.mdwn 
@@ -1,15 +0,0 @@-Running the 'assistant' branch, I occassionally get--To myhost1:/Users/jtang/annex- ! [rejected]        master -> synced/master (non-fast-forward)-error: failed to push some refs to 'myhost1:/Users/jtang/annex'-hint: Updates were rejected because a pushed branch tip is behind its remote-hint: counterpart. Check out this branch and merge the remote changes-hint: (e.g. 'git pull') before pushing again.-hint: See the 'Note about fast-forwards' in 'git push --help' for details.-(Recording state in git...)--manually running a 'git annex sync' usually fixes it, I guess once the sync command runs periodically this problem will go away, is this even OSX specific? I don't quite get the behaviour that is described in [[design/assistant/blog/day_15__its_aliiive]].--> With my changes today, I've seen it successfully recover from this-> situation. [[done]] --[[Joey]]
− doc/bugs/OSX_app_issues/comment_2_fd560811c57df5cbc3976639642b8b19._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkN91jAhoesnVI9TtWANaBPaYjd1V9Pag8"- nickname="Benjamin"- subject="Package for older OS X"- date="2012-11-17T12:36:45Z"- content="""-Is there an option to provide application bundle for older versions of OS X? The last time I tried the bundle wouldn't work under 10.5. If no specific features from newer OS X versions are required, it could be enough to add a simple switch when building.-"""]]
− doc/bugs/OSX_app_issues/comment_3_08613b2e2318680508483d204a43da76._comment 
@@ -1,76 +0,0 @@-[[!comment format=mdwn- username="http://edheil.wordpress.com/"- nickname="edheil"- subject="No luck running it on OS X Lion."- date="2012-11-21T06:07:55Z"- content="""-here's the crash info:--<pre>-Process:         git-annex [84369]-Path:            /Applications/git-annex.app/Contents/MacOS/bin/git-annex-Identifier:      git-annex-Version:         ??? (???)-Code Type:       X86-64 (Native)-Parent Process:  sh [84364]--Date/Time:       2012-11-21 00:27:03.068 -0500-OS Version:      Mac OS X 10.7.5 (11G63)-Report Version:  9--Crashed Thread:  0--Exception Type:  EXC_BREAKPOINT (SIGTRAP)-Exception Codes: 0x0000000000000002, 0x0000000000000000--Application Specific Information:-dyld: launch, loading dependent libraries--Dyld Error Message:-  Library not loaded: /opt/local/lib/libgss.3.dylib-  Referenced from: /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libgsasl.7.dylib-  Reason: image not found--Binary Images:-       0x105baa000 -        0x107b89fe7 +git-annex (??? - ???) <45311C82-015C-3F87-9F9B-01325EFBD0D9> /Applications/git-annex.app/Contents/MacOS/bin/git-annex-       0x10822d000 -        0x10823eff7 +libz.1.dylib (1.2.7 - compatibility 1.0.0) <57016CC1-AD54-337E-A983-457933B24D35> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libz.1.dylib-       0x108245000 -        0x10827dff7 +libpcre.1.dylib (2.1.0 - compatibility 2.0.0) <431BD758-FA7B-38B3-AB7E-6511EC06152E> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libpcre.1.dylib-       0x108283000 -        0x1083b3ff7 +libxml2.2.dylib (11.0.0 - compatibility 11.0.0) <0663F820-D436-3304-B12F-9158901087EB> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libxml2.2.dylib-       0x1083e9000 -        0x108400fef +libgsasl.7.dylib (16.6.0 - compatibility 16.0.0) <41503EE1-D58B-385C-AC2E-BEAA7D0D4E38> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libgsasl.7.dylib-       0x10840a000 -        0x1084a1fff +libgnutls.26.dylib (49.3.0 - compatibility 49.0.0) <0320352A-3336-3B6B-A7DE-F3069669AD27> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libgnutls.26.dylib-       0x1084c3000 -        0x1084f1ff7 +libidn.11.dylib (18.8.0 - compatibility 18.0.0) <97073970-9370-3F85-B943-1B989EA41148> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libidn.11.dylib-       0x1084fc000 -        0x1085f5ff7 +libiconv.2.dylib (8.1.0 - compatibility 8.0.0) <1B8D243B-F617-301E-97B1-EE78A72617AB> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libiconv.2.dylib-       0x108606000 -        0x108606fff +libcharset.1.dylib (2.0.0 - compatibility 2.0.0) <E3797413-2AA3-3698-B393-E1203B4799A0> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libcharset.1.dylib-       0x10860c000 -        0x108665fef +libgmp.10.dylib (11.5.0 - compatibility 11.0.0) <EE407B22-0F44-38B6-9937-10CA6A529F37> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libgmp.10.dylib-       0x108675000 -        0x1086a2fe7 +libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <7BEBB139-50BB-3112-947A-F4AA168F991C> /Applications/git-annex.app/Contents/MacOS/usr/lib/libSystem.B.dylib-       0x1086b4000 -        0x1086c8fef +libgcc_s.1.dylib (??? - ???) <3C5BF0B8-B1E9-3B41-B52F-F7499687217C> /Applications/git-annex.app/Contents/MacOS/opt/local/lib/gcc47/libgcc_s.1.dylib-       0x1086d8000 -        0x1086f5ff7 +liblzma.5.dylib (6.4.0 - compatibility 6.0.0) <1D682E06-EB89-34CA-855A-AEF611C4DF86> /usr/local/lib/liblzma.5.dylib-    0x7fff657aa000 -     0x7fff657debaf  dyld (195.6 - ???) <0CD1B35B-A28F-32DA-B72E-452EAD609613> /usr/lib/dyld-    0x7fff8b669000 -     0x7fff8b672ff7  libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) <A4D651E3-D1C6-3934-AD49-7A104FD14596> /usr/lib/system/libsystem_notify.dylib-    0x7fff8b6e4000 -     0x7fff8b6e5ff7  libsystem_sandbox.dylib (??? - ???) <2A09E4DA-F47C-35CB-B70C-E0492BA9F20E> /usr/lib/system/libsystem_sandbox.dylib-    0x7fff8c000000 -     0x7fff8c006ff7  libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib-    0x7fff8c1c4000 -     0x7fff8c1c5ff7  libremovefile.dylib (21.1.0 - compatibility 1.0.0) <739E6C83-AA52-3C6C-A680-B37FE2888A04> /usr/lib/system/libremovefile.dylib-    0x7fff8cf13000 -     0x7fff8cf4efff  libsystem_info.dylib (??? - ???) <35F90252-2AE1-32C5-8D34-782C614D9639> /usr/lib/system/libsystem_info.dylib-    0x7fff8dbc3000 -     0x7fff8dbc8fff  libcache.dylib (47.0.0 - compatibility 1.0.0) <1571C3AB-BCB2-38CD-B3B2-C5FC3F927C6A> /usr/lib/system/libcache.dylib-    0x7fff8dbc9000 -     0x7fff8dbd0fff  libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <0AB51EE2-E914-358C-AC19-47BC024BDAE7> /usr/lib/system/libcopyfile.dylib-    0x7fff8dbdf000 -     0x7fff8dbedfff  libdispatch.dylib (187.10.0 - compatibility 1.0.0) <8E03C652-922A-3399-93DE-9EA0CBFA0039> /usr/lib/system/libdispatch.dylib-    0x7fff8dcf2000 -     0x7fff8dcf7ff7  libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib-    0x7fff8e1bb000 -     0x7fff8e298fef  libsystem_c.dylib (763.13.0 - compatibility 1.0.0) <41B43515-2806-3FBC-ACF1-A16F35B7E290> /usr/lib/system/libsystem_c.dylib-    0x7fff8e6e2000 -     0x7fff8e6eafff  libsystem_dnssd.dylib (??? - ???) <584B321E-5159-37CD-B2E7-82E069C70AFB> /usr/lib/system/libsystem_dnssd.dylib-    0x7fff8fab6000 -     0x7fff8fab8fff  libquarantine.dylib (36.7.0 - compatibility 1.0.0) <8D9832F9-E4A9-38C3-B880-E5210B2353C7> /usr/lib/system/libquarantine.dylib-    0x7fff8fc3e000 -     0x7fff8fc80ff7  libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) <BB770C22-8C57-365A-8716-4A3C36AE7BFB> /usr/lib/system/libcommonCrypto.dylib-    0x7fff90fa3000 -     0x7fff90fa9fff  libmacho.dylib (800.0.0 - compatibility 1.0.0) <165514D7-1BFA-38EF-A151-676DCD21FB64> /usr/lib/system/libmacho.dylib-    0x7fff90faa000 -     0x7fff90fabfff  libunc.dylib (24.0.0 - compatibility 1.0.0) <337960EE-0A85-3DD0-A760-7134CF4C0AFF> /usr/lib/system/libunc.dylib-    0x7fff910b4000 -     0x7fff910b8fff  libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) <FF83AFF7-42B2-306E-90AF-D539C51A4542> /usr/lib/system/libmathCommon.A.dylib-    0x7fff916b9000 -     0x7fff916bdfff  libdyld.dylib (195.6.0 - compatibility 1.0.0) <FFC59565-64BD-3B37-90A4-E2C3A422CFC1> /usr/lib/system/libdyld.dylib-    0x7fff916be000 -     0x7fff916defff  libsystem_kernel.dylib (1699.32.7 - compatibility 1.0.0) <66C9F9BD-C7B3-30D4-B1A0-03C8A6392351> /usr/lib/system/libsystem_kernel.dylib-    0x7fff916df000 -     0x7fff916e0fff  libdnsinfo.dylib (395.11.0 - compatibility 1.0.0) <853BAAA5-270F-3FDC-B025-D448DB72E1C3> /usr/lib/system/libdnsinfo.dylib-    0x7fff929f8000 -     0x7fff929fdfff  libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib-    0x7fff93a3c000 -     0x7fff93a3cfff  libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib-    0x7fff97139000 -     0x7fff9713aff7  libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib-    0x7fff9724f000 -     0x7fff9726cfff  libxpc.dylib (77.19.0 - compatibility 1.0.0) <9F57891B-D7EF-3050-BEDD-21E7C6668248> /usr/lib/system/libxpc.dylib-    0x7fff97cfe000 -     0x7fff97d08ff7  liblaunch.dylib (392.39.0 - compatibility 1.0.0) <8C235D13-2928-30E5-9E12-2CC3D6324AE2> /usr/lib/system/liblaunch.dylib-</pre>- --"""]]
− doc/bugs/OSX_app_issues/comment_6_12bd83e7e2327c992448e87bdb85d17e._comment 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="https://me.yahoo.com/a/6xTna_B_h.ECb6_ftC2dYLytAEwrv36etg_054U-#4c1e7"- nickname="Fake"- subject="libncurses on 10.7"- date="2012-10-17T21:24:24Z"- content="""-I'm getting an error from gpg when I try to set up a repository on a remote server with encrypted rsync.  Looks like libncurses in /usr/lib is 32 bit:--    Dyld Error Message:-      Library not loaded: /opt/local/lib/libncurses.5.dylib-      Referenced from: /Applications/git-annex.app/Contents/MacOS/opt/local/lib/libreadline.6.2.dylib-      Reason: no suitable image found.  Did find:-  	  /usr/lib/libncurses.5.dylib: mach-o, but wrong architecture-  	  /usr/lib/libncurses.5.dylib: mach-o, but wrong architecture-"""]]
− doc/bugs/OSX_app_issues/comment_6_cea97dbbfb566a9fe463365ca4511119._comment 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="http://nico.kaiser.me/"- nickname="Nico Kaiser"- subject="git-annex crashing on OS X 10.8.2"- date="2012-11-27T08:01:29Z"- content="""-    $ /Applications/git-annex.app/Contents/MacOS/git-annex-webapp-    dyld: Symbol not found: _OBJC_CLASS_$_NSObject-      Referenced from: /usr/bin/open-      Expected in: /Applications/git-annex.app/Contents/MacOS/usr/lib/libobjc.A.dylib-     in /usr/bin/open-    WebApp crashed: failed to start web browser-    -    Launching web browser on file:///var/folders/8g/_fvs7jf572l4fj03q5mhrq9r0000gn/T/webapp1196.html--"""]]
− doc/bugs/OSX_app_issues/comment_7_911f187d46890093a54859032ada2442._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.154.6.49"- subject="comment 7"- date="2012-11-27T21:13:18Z"- content="""-@Nico, that's actually kind of promising; people have been reporting much earlier crashes with OSX. This later crash is one I think I can do something about! :)--So, it looks like the standalone app build needs to run the web browser in a clean environment that doesn't use any of its bundled libraries. I've committed that change and it will be in a release later today.-"""]]
− doc/bugs/OSX_app_issues/comment_7_93e0bb53ac2d7daef53426fbdc5f92d9._comment 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkurjhi0CRJvgm7QNaZDWS9hitBtavqIpc"- nickname="Bret"- subject="git-annex.app Not working on 32 bit machines"- date="2012-11-03T19:18:47Z"- content="""-I tried running the git-annex.app on my Core Duo Macbook pro, and it does not run at all.  I get an error on my system.log--`Nov  3 12:13:26 Bret-Mac [0x0-0x15015].com.branchable.git-annex[155]: /Applications/git-annex.app/Contents/MacOS/runshell: line 52: /Applications/git-annex.app/Contents/MacOS/bin/git-annex: Bad CPU type in executable-Nov  3 12:13:26 Bret-Mac com.apple.launchd.peruser.501[92] ([0x0-0x15015].com.branchable.git-annex[155]): Exited with exit code: 1`--It works on my 64 bit machine, and this has become quite the problem for a while now, where people with newer macs dont compile back for a 32bit machine.  --Is there any hope for a pre-compiled binary that works on a 32 bit machine?-"""]]
− doc/bugs/OSX_app_issues/comment_8_141eac2f3fb25fe18b4268786f00ad6a._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 8"- date="2012-11-07T16:08:00Z"- content="""-I've been updating my haskell platform install recently, i used to try and get the builder to spit out 32/64bit binaries, but recently it's just become too messy, I've just migrated to a full 64bit build system. I'm afraid I won't be able to  provide 32bit builds any more.-"""]]
− doc/bugs/git-annex_has_issues_with_git_when_staging__47__commiting_logs.mdwn 
@@ -1,34 +0,0 @@-After a series of pretty convoluted copying files around between annex'd repos and pulling changes around between repos. I noticed that occassionally when git-annex tries to stage files (the `.git-annex/*/*/*logs`) git some times gets wedged and doing a "git commit -a" doesn't seem to work or files might not get added thus leaving a bunch of untracked files or modified files that aren't staged for a commit.--I tried running a *`git rm --cached -f -r *`* then *git add -u .git-annex/* or the usual *git add* then a commit fixes things for me. If I don't do that then my subsequent merges/pulls will fail and result in *no known copies of files* I suspect git-annex might have just touched some file modes and git picked up the changes but got confused since there was no content change. It might also just be a git on OSX thing and it doesn't affect linux/bsd users.--For now it's just a bit of extra work for me when it does occur but it does not seem to occur often.--> What do you mean when you say that git "got wedged"? It hung somehow?->-> If git-annex runs concurrently with another git command that locks-> the repository, its git add of log files can fail.-> -> Update: Also, of course, if you are running a "got annex get" or-> similar, and ctrl-c it after it has gotten some files, it can-> end up with unstaged or in some cases un-added log files that git-annex-> wrote -- since git-annex only stages log files in git on shutdown, and-> ctrl-c bypasses that.-> --[[Joey]] -->> It "got wedged" as in git doesn't let me commit anything, even though it tells me that there is stuff to be committed in the staging area.-->>> I've never seen git refuse to commit staged files. There would have to->>> be some error message? --[[Joey]] -->>>> there were no error messages at all-->>>>> Can I see a transcript? I'm having difficulty getting my head around->>>>> what git is doing. Sounds like the files could just not be `git->>>>> added` yet, but I get the impression from other things that you say->>>>> that it's not so simple. --[[Joey]] --This turns out to be a bug in git, and I have posted a bug report on the mailing list.-The git-annex behavior that causes this situation is being handled as-another bug, [[git-annex directory hashing problems on osx]].-So, closing this bug report. [[done]] --[[Joey]]
− doc/bugs/git_annex_gets_confused_about_remotes_with_dots_in_their_names.mdwn 
@@ -1,34 +0,0 @@-For test.com//test, I get this:--    % git annex copy . --to test.com//test-    (getting UUID for test...) git-annex: there is no git remote named "test.com//test"--And my .git/config changes from--    [remote "test.com//test"]-    	url = richih@test.com:/test-    	fetch = +refs/heads/*:refs/remotes/test.com//test/*--to--    [remote "test.com//test"]-    	url = richih@test.com:/test-    	fetch = +refs/heads/*:refs/remotes/test.com//test/*-    	annex-uuid = xyz-    [remote "test"]-    	annex-uuid = xyz---Unless I am misunderstanding something, git annex gets confused about what the name of the remote it supposed to be, truncates at the dot for some operations and uses the full name for others.--> I've fixed this bug. [[done]]-> -> However, using "/" in a remote name seems likely to me to confuse -> git's own remote branch handling. Although I've never tried it.-> --[[Joey]] -->> From what I can see, git handles / just fine, but would get upset about : which is why it's not allowed in a remote's name.->> My naming scheme is host//path/to/annex. It sorts nicely and gives all important information left to right with the most specific parts at the beginning and end.->> If you have any other ideas or scheme, I am all ears :)->> Either way, thanks for fixing this so quickly.->> -- RichiH
− doc/bugs/git_defunct_processes___40__child_of_git-annex_assistant__41__.mdwn 
@@ -1,34 +0,0 @@-What steps will reproduce the problem?--run git annex assistant, add a file, which is picked up and pushed by the assistant.  --What is the expected output? What do you see instead?--a ps -ef shows a large number of defunct git processes.. for example:-<pre>-nelg      9622     1  0 02:01 ?        00:00:01 git-annex assistant-nelg      9637  9622  0 02:01 ?        00:00:00 git --git-dir=/home/nelg/Downloads/test2/.git --work-tree=/home/nelg/Downloads/test2 cat-file --batch-nelg     12080  9622  0 02:19 ?        00:00:00 [git] &lt;defunct&gt;-nelg     12082  9622  0 02:19 ?        00:00:00 [git] &lt;defunct&gt;-nelg     12083  9622  0 02:19 ?        00:00:00 [git] &lt;defunct&gt;-nelg     12084  9622  0 02:19 ?        00:00:00 [git] &lt;defunct&gt;-------</pre>--What version of git-annex are you using? On what operating system?--Compiled git annex from git (cbcd208d158f8e42dda03a5eeaf1bac21045a140), on Mandriva 2010.2, 32 bit, using ghc-7.4.1.- git version 1.7.1---Please provide any additional information below.--I also found that the version of git I have does not support the option: --allow-empty-message-So, suggest that if the version of git installed is an older version, that the params in  Assistant/Threads/Committer.hs-are changed to  [ Param "-m", Param "git assistant".... or something like that.--I have done this on my copy for testing it.--For testing, I am also using two repositories on the same computer.  I set this up from the command line, as the web app does not seem to support syncing to two different git folders on the same computer.--> [[done]]; all zombies are squelched now in the assistant. --[[Joey]]
− doc/bugs/wishlist:_more_descriptive_commit_messages_in_git-annex_branch.mdwn 
@@ -1,39 +0,0 @@-as of git-annex version 3.20110719, all git-annex commits only contain the word "update" as a commit message. given that the contents of the commit are pretty non-descriptive (SHA1 hashes for file names, uuids for repository names), i suggest to have more descriptive commit messages, as shown here:--    /mnt/usb_disk/photos/2011$ git annex get-    /mnt/usb_disk/photos/2011$ git show git-annex-    [...]-    usb-disk-photos: get 2011-    -    * 10 files retrieved from 2 sources (9 from local-harddisk, 1 from my-server)-    * 120 files were already present-    * 2 files could not be retrieved-    /mnt/usb_disk/photos/2011$ cd ~/photos/2011/07-    ~/photos/2011/07$ git copy --to my-server-    ~/photos/2011/07$ git show git-annex-    [...]-    local-harddisk: copy 2011/07 to my-server-    -    * 20 files pushed-    ~/photos/2011/07$--in my opinion, the messages should at least contain--* what command was used-* in which repository they were executed-* which files or directories they affected (not necessarily all files, but what was given on command line or implicitly from the working directory)----[[chrysn]]--> The implementation of the git-annex branch precludes more descriptive-> commit messages, since a single commit can include changes that were-> previously staged to the branch's index file, or spooled to its journal-> by other git-annex commands (either concurrently running or-> interrupted commands, or even changes needed to automatically merge-> other git-annex branches).-> -> It would be possible to make it *less* verbose, with an empty commit-> message. :) --[[Joey]] -->> Closing as this is literally impossible to do without making->> git-annex worse. [[done]] --[[Joey]]
− doc/design/assistant/OSX/comment_1_9290f6e6f265e906b08631224392b7bf._comment 
@@ -1,14 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawlu-fdXIt_RF9ggvg4zP0yBbtjWQwHAMS4"- nickname="Jörn"- subject="Mount detection"- date="2012-09-21T09:23:34Z"- content="""-regarding the current mount polling on OSX: why not use the NSNotificationCenter for being notified on mount events on OSX?--Details see:--1. <http://stackoverflow.com/questions/12409458/detect-when-a-volume-is-mounted-on-os-x>-2. <http://stackoverflow.com/questions/6062299/how-to-add-an-observer-to-nsnotificationcenter-in-a-c-class-using-objective-c>-3. <https://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFNotificationCenterRef/Reference/reference.html#//apple_ref/doc/uid/20001438>-"""]]
− doc/design/assistant/blog/day_81__enabling_pre-existing_special_remotes.mdwn 
@@ -1,34 +0,0 @@-It's possible for one git annex repository to configure a special remote-that it makes sense for other repositories to also be able to use. Today I-added the UI to support that; in the list of repositories, such-repositories have a "enable" link.--To enable pre-existing rsync special remotes, the webapp has to do the same-probing and ssh key setup that it does when initially creating them.-Rsync.net is also handled as a special case in that code. There was one-ugly part to this.. When a rsync remote is configured in the webapp,-it uses a mangled hostname like "git-annex-example.com-user", to-make ssh use the key it sets up. That gets stored in the `remote.log`, and so-the enabling code has to unmangle it to get back to the real hostname.-------Based on the still-running [[prioritizing_special_remotes]] poll, a lot-of people want special remote support for their phone or mp3 player.-(As opposed to running git-annex on an Android phone, which comes later..)-It'd be easy enough to make the webapp set up a directory special remote-on such a device, but that makes consuming some types of content on the-phone difficult (mp3 players seem to handle them ok based on what people tell-me). I need to think more about some of the ideas mentioned in [[android]]-for more suitable ways of storing files.--One thing's for sure: You won't want the assistant to sync all your files-to your phone! So I also need to start coming up with partial syncing-controls. One idea is for each remote to have a configurable matcher for files-it likes to receive. That could be only mp3 files, or all files inside a-given subdirectory, or all files *not* in a given subdirectory. That means-that when the assistant detects a file has been moved, it'll need to add-(or remove) a queued transfer. Lots of other things could be matched on,-like file size, number of copies, etc. Oh look, I have a-[beautiful library I wrote earlier](http://joeyh.name/blog/entry/happy_haskell_hacker)-that I can reuse!
− doc/forum/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults.mdwn 
@@ -1,17 +0,0 @@-I am running centralized git-annex exclusively.--Similar to--    git annex get--I'd like to have a--    git annex put--which would put all files on the default remote(s).--My main reason for not wanting to use copy --to is that I need to specify the remote's name in this case which makes writing a wrapper unnecessarily hard. Also, this would allow--    mr push--to do the right thing all by itself.
doc/git-annex.mdwn view
@@ -522,7 +522,8 @@    Rather than the normal output, generate JSON. This is intended to be   parsed by programs that use git-annex. Each line of output is a JSON-  object.+  object. Note that json output is only usable with some git-annex commands,+  like status and find.  * --debug
− doc/special_remotes/bup/comment_1_96179a003da4444f6fc08867872cda0a._comment 
@@ -1,43 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkgbXwQtPQSG8igdS7U8l031N8sqDmuyvk"- nickname="Albert"- subject="Error with bup and gnupg"- date="2012-10-22T20:56:56Z"- content="""-Hello,--I get this error when trying to use git-annex with bup and gnupg:--<pre>-move importable_pilot_surveys.tar (gpg) (checking localaseebup...) (to localaseebup...) -Traceback (most recent call last):-  File \"/usr/lib/bup/cmd/bup-split\", line 133, in <module>-    progress=prog)-  File \"/usr/lib/bup/bup/hashsplit.py\", line 167, in split_to_shalist-    for (sha,size,bits) in sl:-  File \"/usr/lib/bup/bup/hashsplit.py\", line 118, in _split_to_blobs-    for (blob, bits) in hashsplit_iter(files, keep_boundaries, progress):-  File \"/usr/lib/bup/bup/hashsplit.py\", line 86, in _hashsplit_iter-    bnew = next(fi)-  File \"/usr/lib/bup/bup/helpers.py\", line 86, in next-    return it.next()-  File \"/usr/lib/bup/bup/hashsplit.py\", line 49, in blobiter-    for filenum,f in enumerate(files):-  File \"/usr/lib/bup/cmd/bup-split\", line 128, in <genexpr>-    files = extra and (open(fn) for fn in extra) or [sys.stdin]-IOError: [Errno 2] No such file or directory: '-'-</pre>---I was able to work-around this issue by altering /usr/lib/bup/cmd/bup-split (though I don't think its a bup bug) to just pull from stdin:--files = [sys.stdin]--on ~ line 128.--Any ideas? Also, do you think that bup's data-deduplication does anything when gnupg is enabled, i.e. is it just as well to use a directory remote with gnupg?--Thanks! Git annex rules!--Albert-"""]]
− doc/special_remotes/bup/comment_2_612b038c15206f9f3c2e23c7104ca627._comment 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.154.0.23"- subject="comment 2"- date="2012-10-23T20:01:43Z"- content="""-@Albert, thanks for reporting this bug (but put them in [[bugs]] in future please).--This is specific to using the bup special remote with encryption. Without encryption it works. And no, it won't manage to deduplicate anything that's encrypted, as far as I know. --I think bup-split must have used - for stdin in the past, but now, it just reads from stdin when no file is specified, so I've updated git-annex.-"""]]
− doc/special_remotes/hook/comment_1_6a74a25891974a28a8cb42b87cb53c26._comment 
@@ -1,32 +0,0 @@-[[!comment format=mdwn- username="helmut"- ip="89.0.176.236"- subject="Asynchronous hooks?"- date="2012-10-13T09:46:14Z"- content="""-Is there a way to use asynchronous remotes? Interaction with git annex would have to-split the part of initiating some action from completing it.--I imagine I could `git annex copy` a file to an asynchronous remote and the command-would almost immediately complete. Later I would learn that the transfer is-completed, so the hook must be able to record that information in the `git-annex`-branch. An additional plumbing command seems required here as well as a way to-indicate that even though the store-hook completed, the file is not transferred.--Similarly `git annex get` would immediately return without actually fetching the-file. This should already be possible by returning non-zero from the retrieve-hook.-Later the hook could use plumbing level commands to actually stick the received file-into the repository.--The remove-hook should need no changes, but the checkpresent-hook would be more like-a trigger without any actual result. The extension of the plumbing required for the-extension to the receive-hook could update the location log. A downside here is that-you never know when a fsck has completed.--My proposal does not include a way to track the completion of actions, but relies on-the hook to always complete them reliably. It is not clear that this is the best road-for asynchronous hooks.--One use case for this would be a remote that is only accessible via uucp. Are there-other use cases? Is the drafted interface useful?-"""]]
− doc/tips/assume-unstaged/comment_1_44abd811ef79a85e557418e17a3927be._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://me.yahoo.com/a/2djv2EYwk43rfJIAQXjYt_vfuOU-#a11a6"- nickname="Olivier R"- subject="It doesn't work 100%"- date="2012-05-03T21:42:54Z"- content="""-When you remove tracked files... it doesn't show the new status. it's like if the file was ignored.---"""]]
− doc/tips/using_Amazon_S3/comment_1_666a26f95024760c99c627eed37b1966._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnoUOqs_lbuWyZBqyU6unHgUduJwDDgiKY"- nickname="Matt"- subject="ANNEX_S3 vs AWS for keys"- date="2012-05-29T12:24:25Z"- content="""-The instructions state ANNEX_S3_ACCESS_KEY_ID and ANNEX_SECRET_ACCESS_KEY but git-annex cannot connect with those constants. git-annex tells me to set both \"AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY\" instead, which works. This is with Xubuntu 12.04.-"""]]
− doc/tips/using_Amazon_S3/comment_2_f5a0883be7dbb421b584c6dc0165f1ef._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.81.112"- subject="comment 2"- date="2012-05-29T19:10:42Z"- content="""-Thanks, I've fixed that. (You could have too.. this is a wiki ;)-"""]]
− doc/todo/cache_key_info/comment_1_578df1b3b2cbfdc4aa1805378f35dc48._comment 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 1"- date="2011-05-17T07:27:02Z"- content="""-Sounds like a good idea.--* git annex fsck (or similar) should check/rebuild the caches-* I would simply require a clean tree with a verbose error. 80/20 rule and defaulting to save actions.-"""]]
− doc/todo/windows_support/comment_1_3cc26ad8101a22e95a8c60cf0c4dedcc._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkRITTYYsN0TFKN7G5sZ6BWGZOTQ88Pz4s"- nickname="Zoltán"- subject="cygwin"- date="2012-05-15T00:14:08Z"- content="""-What about [Cygwin](http://cygwin.com/)? It emulates POSIX fairly well under Windows (including signals, forking, fs (also things like /dev/null, /proc), unix file permissions), has all standard gnu utilities. It also emulates symlinks, but they are unfortunately incompatible with NTFS symlinks introduced in Vista [due to some stupid restrictions on Windows](http://cygwin.com/ml/cygwin/2009-10/msg00756.html).--If git-annex could be modified to not require symlinks to work, the it would be a pretty neat solution (and you get a real shell, not some command.com on drugs (aka cmd.exe))-"""]]
− doc/todo/windows_support/comment_2_8acae818ce468967499050bbe3c532ea._comment 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawk5cj-itfFHq_yhJHdzk3QOPp-PNW_MjPU"- nickname="Michael"- subject="+1 Cygwin"- date="2012-05-23T19:30:21Z"- content="""-Windows support is a must. In my experience, binary file means proprietary editor, which means Windows.--Unfortunately, there's not much overlap between people who use graphical editors in Windows all day vs. people who are willing to tolerate Cygwin's setup.exe, compile a Haskell program, learn git and git-annex's 90-odd subcommands, and use a mintty terminal to manage their repository, especially now that there's a sexy GitHub app for Windows.--That aside, I think Windows-based content producers are still *the* audience for git-annex. First Windows support, then a GUI, then the world.-"""]]
− doc/todo/windows_support/comment_3_bd0a12f4c9b884ab8a06082842381a01._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://xolus.net/openid/max"- nickname="B0FH"- subject="What about NTFS support ?"- date="2012-08-02T17:45:10Z"- content="""-Has git-annex been tested with an NTFS-formatted disk under Linux ? NTFS is supposed to be case-sensitive and to allow symlinks, and these are supposed to work with ntfs3g.-"""]]
− doc/todo/windows_support/comment_4_ad06b98b2ddac866ffee334e41fee6a8._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawlc1og3PqIGudOMkFNrCCNg66vB7s-jLpc"- nickname="Paul"- subject="Re: What about NTFS support?"- date="2012-08-16T19:30:38Z"- content="""-I successfully use git-annex on an NTFS formatted external USB drive, so yes, it is possible and works well.-"""]]
− doc/todo/windows_support/comment_5_444fc7251f57db241b6e80abae41851c._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://me.yahoo.com/a/dASECLNzvckz4VwqUGYsvthiplY.#d2c27"- nickname="A. D. Sicks"- subject="comment 5"- date="2012-09-09T23:48:21Z"- content="""-Haskell has C++ binding, so it should be possible to port it to .net/Mono with a VB GUI for Windows users.  Windows has a primitive form of symlinks called shortcuts.  Perhaps shortcut support in Windows could replace the use of symlinks.  I've used shortcuts since XP to put my home Windows directory on another partition and never had a hitch...--If anyone is interested in working on this, hit me up.  I would like to use this in my XP vbox to have access to files on my host OS...I have a student edition of Visual Studio 2005 to do an open source port...-"""]]
git-annex.1 view
@@ -465,7 +465,8 @@ .IP "\-\-json" Rather than the normal output, generate JSON. This is intended to be parsed by programs that use git\-annex. Each line of output is a JSON-object.+object. Note that json output is only usable with some git\-annex commands,+like status and find. .IP .IP "\-\-debug" Show debug messages.
git-annex.cabal view
@@ -1,5 +1,5 @@ Name: git-annex-Version: 3.20121127+Version: 3.20121127.1 Cabal-Version: >= 1.8 License: GPL Maintainer: Joey Hess <joey@kitenet.net>