packages feed

git-annex 3.20120614 → 3.20120615

raw patch · 272 files changed

+25/−3845 lines, 272 filesbinary-added

Files

+ .make-sdist.sh.swo view

binary file changed (absent → 12288 bytes)

+ .make-sdist.sh.swp view

binary file changed (absent → 4096 bytes)

CHANGELOG view
@@ -1,4 +1,4 @@-git-annex (3.20120614) unstable; urgency=medium+git-annex (3.20120615) unstable; urgency=medium    * addurl: Was broken by a typo introduced 2 released ago, now fixed.     Closes: #677576
Makefile view
@@ -100,8 +100,6 @@ 	rm -rf tmp $(bins) $(mans) test configure  *.tix .hpc $(sources) \ 		doc/.ikiwiki html dist $(clibs) -# Workaround for `cabal sdist` requiring all included files to be listed-# in .cabal. sdist: clean $(mans) 	./make-sdist.sh
+ debian/.changelog.swp view

binary file changed (absent → 16384 bytes)

debian/changelog view
@@ -1,4 +1,4 @@-git-annex (3.20120614) unstable; urgency=medium+git-annex (3.20120615) unstable; urgency=medium    * addurl: Was broken by a typo introduced 2 released ago, now fixed.     Closes: #677576
− doc/bugs/Cabal_dependency_monadIO_missing/comment_1_14be660aa57fadec0d81b32a8b5 
@@ -1,75 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawmFgsNxmnGznb5bbmcoWhoQOoxZZ-io61s"- nickname="Thomas"- subject="comment 1"- date="2011-08-08T09:04:20Z"- content="""-I use Debian Squeeze, I have the Debian package cabal-install 0.8.0-1 installed.--    $ git clone git://git-annex.branchable.com/-    $ cd git-annex.branchable.com-    $ cabal update-    $ cabal install cabal-install--This installed: Cabal-1.10.2.0, zlib-0.5.3.1, cabal-install 0.10.2.-No version of monad-control or monadIO installed.--    $ ~/.cabal/bin/cabal install-    Registering QuickCheck-2.4.1.1...-    Registering Crypto-4.2.3...-    Registering base-unicode-symbols-0.2.2.1...-    Registering deepseq-1.1.0.2...-    Registering hxt-charproperties-9.1.0...-    Registering hxt-regex-xmlschema-9.0.0...-    Registering hxt-unicode-9.0.1...-    Registering hxt-9.1.2...-    Registering stm-2.2.0.1...-    Registering hS3-0.5.6...-    Registering transformers-0.2.2.0...-    Registering monad-control-0.2.0.1...-    [1 of 1] Compiling Main             ( Setup.hs, dist/setup/Main.o )-    Linking ./dist/setup/setup ...-    ghc -O2 -Wall -ignore-package monads-fd -fspec-constr-count=5 --make configure-    [1 of 2] Compiling TestConfig       ( TestConfig.hs, TestConfig.o )-    [2 of 2] Compiling Main             ( configure.hs, configure.o )-    Linking configure ...-    ./configure-      checking version... 3.20110720-      checking cp -a... yes-      checking cp -p... yes-      checking cp --reflink=auto... yes-      checking uuid generator... uuid-      checking xargs -0... yes-      checking rsync... yes-      checking curl... yes-      checking bup... yes-      checking gpg... yes-      checking sha1... sha1sum-      checking sha256... sha256sum-      checking sha512... sha512sum-      checking sha224... sha224sum-      checking sha384... sha384sum--    ...--    Command/Add.hs:54:3:-        No instance for (Control.Monad.IO.Control.MonadControlIO-                           (Control.Monad.State.Lazy.StateT Annex.AnnexState IO))-          arising from a use of `handle' at Command/Add.hs:54:3-24-        Possible fix:-          add an instance declaration for-          (Control.Monad.IO.Control.MonadControlIO-             (Control.Monad.State.Lazy.StateT Annex.AnnexState IO))-        In the first argument of `($)', namely `handle (undo file key)'-        In a stmt of a 'do' expression:-              handle (undo file key) $ moveAnnex key file-        In the expression:-            do { handle (undo file key) $ moveAnnex key file;-                 next $ cleanup file key }-    cabal: Error: some packages failed to install:-    git-annex-3.20110719 failed during the building phase. The exception was:-    ExitFailure 1--After I added a depencency for monadIO to the git-annex.cabal file, it installed correctly.  --- Thomas-"""]]
− doc/bugs/Cabal_dependency_monadIO_missing/comment_2_4f4d8e1e00a2a4f7e8a8ab082e1 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-08-17T04:56:30Z"- content="""-Finally got a chance to try to reproduce this. I followed your recipe exactly in a clean squeeze chroot. monadIO was not installed, but git-annex built ok, using monad-control.-"""]]
− doc/bugs/Displayed_copy_speed_is_wrong/comment_1_74de3091e8bfd7acd6795e61f39f07 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-04-03T01:37:29Z"- content="""-That is displayed by rsync. It's not unheard of for rsync to resume a transfer and display extremely high speeds.-"""]]
− doc/bugs/Displayed_copy_speed_is_wrong/comment_2_8b240de1d5ae9229fa2d77d1cc15a5 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 2"- date="2011-04-03T08:56:48Z"- content="""-Pity. Mark as done/upstream (or similar) for house-keeping?-"""]]
− doc/bugs/Error_while_adding_a_file___34__createSymbolicLink:_already_exists__34 
@@ -1,46 +0,0 @@-I'm importing a directory where some files are hard links of each other.--This is confusing git-annex. Here's a small test of that:--<pre>-paulproteus@pathi:/tmp$ mkdir annex-test-paulproteus@pathi:/tmp$ cd annex-test-paulproteus@pathi:/tmp/annex-test$ git init-Initialized empty Git repository in /tmp/annex-test/.git/-paulproteus@pathi:/tmp/annex-test$ git annex init testing-init testing ok-paulproteus@pathi:/tmp/annex-test$ echo '* annex.backend=SHA1' >> .gitattributes -paulproteus@pathi:/tmp/annex-test$ git commit .gitattributes -m 'Default to sha1'-[master dd54b41] Default to sha1- 1 files changed, 1 insertions(+), 0 deletions(-)-paulproteus@pathi:/tmp/annex-test$ echo "Look at me" > file1-paulproteus@pathi:/tmp/annex-test$ cp -l file1 file2-paulproteus@pathi:/tmp/annex-test$ git annex add file1-add file1 (checksum...) ok-(Recording state in git...)-paulproteus@pathi:/tmp/annex-test$ git commit -m 'So far, so good'-[master eb43084] So far, so good- 2 files changed, 2 insertions(+), 0 deletions(-)- create mode 100644 .git-annex/9a3/f1f/SHA1-s11--b9c599d64212934582d676c722cf3ec61f60e09c.log- create mode 120000 file1-paulproteus@pathi:/tmp/annex-test$ git annex add file2-add file2 (checksum...) -  git-annex: .git/annex/objects/PM/7p/SHA1-s11--b9c599d64212934582d676c722cf3ec61f60e09c/SHA1-s11--b9c599d64212934582d676c722cf3ec61f60e09c: createSymbolicLink: already exists (File exists)-git-annex: 1 failed-paulproteus@pathi:/tmp/annex-test$ -</pre>--When trying to make a small test case for this bug, I noticed that if file1 and file2 have the same contents but are not hard links of each other, they both get annexed just fine.--I think the right behavior here is to annex file2 just fine, as if they weren't hard links before.----- Asheesh.--> The same thing happens anytime the key for a file collides with a key-> already in the annex, AFAICS. (Including when the files have the same-> content but are not hard links... unless you're using WORM backend.)-> -> I've fixed this bug. The first file in wins. See commit for some-> interesting discussion about why it should not check for hash collisions-> in this situation. [[done]] --[[Joey]]
− doc/bugs/Makefile_is_missing_dependancies/comment_1_5a3da5f79c8563c7a450aa29728 
@@ -1,47 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 1"- date="2011-03-23T08:21:30Z"- content="""-Just did some minor digging around and checking, this seems to satisfy the compilers etc... I have yet to confirm that it *really* is working as expected. Also it might be better to check for a darwin operating system instead of apple I think, though I don't know of any one really using a pure darwin OS. But for now it works (I think)--<pre>-From fbfe27c2e19906ac02e3673b91bffa920f6dae5d Mon Sep 17 00:00:00 2001-From: Jimmy Tang <jtang@tchpc.tcd.ie>-Date: Wed, 23 Mar 2011 08:15:39 +0000-Subject: [PATCH] Define (__APPLE__) in StatFS--At least on OSX 10.6.6 it appears to have the same defintions as-FreeBSD. The build process doesn't complain and the code is enabled,-this needs to be tested and checked more.----- StatFS.hsc |    4 ++--- 1 files changed, 2 insertions(+), 2 deletions(-)--diff --git a/StatFS.hsc b/StatFS.hsc-index 8b453dc..45fd7e4 100644---- a/StatFS.hsc-+++ b/StatFS.hsc-@@ -53,7 +53,7 @@ import Foreign.C.String- import Data.ByteString (useAsCString)- import Data.ByteString.Char8 (pack)- --#if defined (__FreeBSD__)-+#if defined (__FreeBSD__) || defined(__APPLE__)- # include <sys/param.h>- # include <sys/mount.h>- #else-@@ -84,7 +84,7 @@ data CStatfs- #ifdef UNKNOWN- #warning free space checking code not available for this OS- #else--#if defined(__FreeBSD__)-+#if defined(__FreeBSD__) || defined(__APPLE__)- foreign import ccall unsafe \"sys/mount.h statfs\"- #else- foreign import ccall unsafe \"sys/vfs.h statfs64\"--- -1.7.4.1-</pre>-"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_2_416f12dbd0c2b841fac8164645b 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-03-23T15:05:12Z"- content="""-There's a simple test -- just configure annex.diskreserve to be say, 10 megabytes less than the total free space on your disk. Then try to git annex get a 11 mb file, and a 9 mb file. :)-"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_3_c38b6f4abc9b9ad413c3b83ca04 
@@ -1,25 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-03-23T15:13:33Z"- content="""-Alternatively, you can just load it up in ghci and see if it reports numbers that make sense:--<pre>-joey@gnu:~/src/git-annex>make StatFS.hs-hsc2hs StatFS.hsc-perl -i -pe 's/^{-# INCLUDE.*//' StatFS.hs-joey@gnu:~/src/git-annex>ghci StatFS.hs-GHCi, version 6.12.1: http://www.haskell.org/ghc/  :? for help-Loading package ghc-prim ... linking ... done.-Loading package integer-gmp ... linking ... done.-Loading package base ... linking ... done.-[1 of 1] Compiling StatFS           ( StatFS.hs, interpreted )-Ok, modules loaded: StatFS.-*StatFS> s <- getFileSystemStats \".\"-Loading package bytestring-0.9.1.5 ... linking ... done.-*StatFS> s-Just (FileSystemStats {fsStatBlockSize = 4096, fsStatBlockCount = 7427989, fsStatByteCount = 30425042944, fsStatBytesFree = 2528489472, fsStatBytesAvailable = 2219384832, fsStatBytesUsed = 27896553472})-</pre>-"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_4_cc13873175edf19104728270031 
@@ -1,30 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 4"- date="2011-03-23T16:02:34Z"- content="""-Ok, well it looks like it isn't doing anything useful at all.--<pre>-jtang@x00:~/develop/git-annex $ make StatFS.hs                                                                                                                                    -hsc2hs StatFS.hsc-perl -i -pe 's/^{-# INCLUDE.*//' StatFS.hs-jtang@x00:~/develop/git-annex $ ghci StatFS.hs                                                                                                                                    -GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help-Loading package ghc-prim ... linking ... done.-Loading package integer-gmp ... linking ... done.-Loading package base ... linking ... done.-Loading package ffi-1.0 ... linking ... done.-[1 of 1] Compiling StatFS           ( StatFS.hs, interpreted )-Ok, modules loaded: StatFS.-*StatFS> s <- getFileSystemStats \".\"-Loading package bytestring-0.9.1.7 ... linking ... done.-*StatFS> s-Just (FileSystemStats {fsStatBlockSize = 0, fsStatBlockCount = 1048576, fsStatByteCount = 0, fsStatBytesFree = 0, fsStatBytesAvailable = 0, fsStatBytesUsed = 0})-*StatFS> s <- getFileSystemStats \"/\"-*StatFS> s-Just (FileSystemStats {fsStatBlockSize = 0, fsStatBlockCount = 1048576, fsStatByteCount = 0, fsStatBytesFree = 0, fsStatBytesAvailable = 0, fsStatBytesUsed = 0})-*StatFS> -</pre>-"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_5_0a1c52e2c96d19b9c3eb7e99b8c 
@@ -1,59 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 5"- date="2011-03-23T16:14:22Z"- content="""-Actually I may have just been stupid and should have read the man page on statfs...--<pre>-jtang@x00:~/develop/git-annex $ git diff-diff --git a/StatFS.hsc b/StatFS.hsc-index 8b453dc..e10b2dd 100644---- a/StatFS.hsc-+++ b/StatFS.hsc-@@ -53,7 +53,7 @@ import Foreign.C.String- import Data.ByteString (useAsCString)- import Data.ByteString.Char8 (pack)- --#if defined (__FreeBSD__)-+#if defined (__FreeBSD__) || defined (__APPLE__)- # include <sys/param.h>- # include <sys/mount.h>- #else-@@ -84,8 +84,8 @@ data CStatfs- #ifdef UNKNOWN- #warning free space checking code not available for this OS- #else--#if defined(__FreeBSD__)--foreign import ccall unsafe \"sys/mount.h statfs\"-+#if defined(__FreeBSD__) || defined (__APPLE__)-+foreign import ccall unsafe \"sys/mount.h statfs64\"- #else- foreign import ccall unsafe \"sys/vfs.h statfs64\"- #endif-</pre>--yields this...--<pre>-jtang@x00:~/develop/git-annex $ ghci StatFS.hs                                                                                                                                    -GHCi, version 6.12.3: http://www.haskell.org/ghc/  :? for help-Loading package ghc-prim ... linking ... done.-Loading package integer-gmp ... linking ... done.-Loading package base ... linking ... done.-Loading package ffi-1.0 ... linking ... done.-[1 of 1] Compiling StatFS           ( StatFS.hs, interpreted )-Ok, modules loaded: StatFS.-*StatFS> s <- getFileSystemStats \".\"-Loading package bytestring-0.9.1.7 ... linking ... done.-*StatFS> s-Just (FileSystemStats {fsStatBlockSize = 4096, fsStatBlockCount = 244106668, fsStatByteCount = 999860912128, fsStatBytesFree = 423097798656, fsStatBytesAvailable = 422835654656, fsStatBytesUsed = 576763113472})-*StatFS> -</pre>---we could just stick another if defined (__APPLE__) instead of what I previously had and it looks like it will do the right thing on OSX.---"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_6_24119fc5d5963ce9dd669f7dcf0 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 6"- date="2011-03-23T16:23:56Z"- content="""-I forgot to mention that the statfs64 stuff in OSX seems to be deprecated, see http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/statfs64.2.html--on a slightly different note, is anonymous pushing to the \"wiki\" over git allowed? I'd prefer to be able to edit stuff inline for updating some of my own comments if I can :P-"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_7_96fd4725df4b54e670077a18d3a 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 7"- date="2011-03-23T16:57:56Z"- content="""-Try the changes I've pushed to use statfs64 on apple.--There is actually a standardized statvfs that I'd rather use, but after the last time that I tried going with the POSIX option first only to find it was not broadly implemented, I was happy to find some already existing code that worked for some OSs.--(While ikiwiki supports anonymous git push, it's a feature we have not rolled out on Branchable.com yet, and anyway, ikiwiki disallows editing existing comments that way. I would, however, be happy to git pull changes from somewhere.)-"""]]
− doc/bugs/Makefile_is_missing_dependancies/comment_8_a3555e3286cdc2bfeb9cde0ff72 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 8"- date="2011-03-23T17:03:51Z"- content="""-The latest change looks good, it seems to be returning sensible numbers for me. Just tried it out on a few different mount points and it appears to be working.-"""]]
− doc/bugs/Prevent_accidental_merges/comment_1_4c46a193915eab8f308a04175cb2e40a._ 
@@ -1,8 +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-10-23T15:00:48Z"- content="""-Having run into the same issue again, I still think git-annex should ensure no merges take place. The clutter introduced by a .gitnomerge is neglible, imo.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_10_94e4ac430140042a2d0fb5a16d86b4 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 10"- date="2011-02-09T15:04:50Z"- content="""-I don't know what these problems forking could be. Can you strace it?-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_11_56f1143fa191361d63b441741699e1 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 11"- date="2011-02-09T19:35:47Z"- content="""-I got dtruss to give me a trace, the output is quite big to post here (~560kb gzip'd), do you mind if I emailed it or posted it somewhere else for you?-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_12_ec5131624d0d2285d3b6880e47033f 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 12"- date="2011-02-09T19:47:30Z"- content="""-joey@kitenet.net (hope I can make sense of dtruss output)-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_13_88ed095a448096bf8a69015a04e64d 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 13"- date="2011-02-09T21:59:47Z"- content="""-The dtrace puzzlingly does not have the same errors shown above, but a set of mostly new errors. I don't know what to make of that.--> git-annex: git-annex/.t/repo/.git/hooks/pre-commit: fileAccess: permission denied (Operation not permitted)--This seems to be caused by it setting the execute bit on the file. I don't know why that would fail; it's just written the file and renamed it into place so clearly should be able to write to it.--> was able to modify annexed file's sha1foo content--This also suggests something breaking with permissions.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_14_89a960b6706ed703b390a81a8bc4e3 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 14"- date="2011-02-12T21:19:24Z"- content="""-I've been trying to dig around the trace and code, and used google to see if the forkProcess issue was a haskell thing or an OSX thing. It seems that <http://hackage.haskell.org/trac/ghc/ticket/4493> someone may have ran into a similar issue, though I am not sure if its related.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_15_6b8867b8e48bf807c955779c9f8f09 
@@ -1,71 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 15"- date="2011-02-13T02:45:51Z"- content="""-It may be possible that OSX has some low resource limits, for user processes (266 per user I think) doing a --    sudo sysctl -w kern.maxproc=2048-    sudo sysctl -w kern.maxprocperuid=1024-    sudo echo \"limit maxfiles 1024 unlimited\" >> /etc/launchd.conf-    sudo echo \"limit maxproc 1024 2048\" >> /etc/launchd.conf--seems to change the behaviour of the tests abit...--<pre>-Testing 1:blackbox:3:git-annex unannex:1:with content                         -### Failure in: 1:blackbox:3:git-annex unannex:1:with content-foo is not a symlink-Testing 1:blackbox:4:git-annex drop:0:no remotes                              -### Failure in: 1:blackbox:4:git-annex drop:0:no remotes-drop wrongly succeeded with no known copy of file-Testing 1:blackbox:4:git-annex drop:1:with remote                             -Testing 1:blackbox:4:git-annex drop:2:untrusted remote                        -Testing 1:blackbox:5:git-annex get                                            -Testing 1:blackbox:6:git-annex move                                           -Testing 1:blackbox:7:git-annex copy                                           -Testing 1:blackbox:8:git-annex unlock/lock                                    -Testing 1:blackbox:9:git-annex edit/commit:0                                  -Cases: 30  Tried: 20  Errors: 0  Failures: 2add foo ok-ok-Testing 1:blackbox:9:git-annex edit/commit:1                                  -Testing 1:blackbox:10:git-annex fix                                           -Testing 1:blackbox:11:git-annex trust/untrust/semitrust                       -Testing 1:blackbox:12:git-annex fsck:0                                        -Cases: 30  Tried: 24  Errors: 0  Failures: 2  Only 1 of 2 trustworthy copies of foo exist.-  Back it up with git-annex copy.-  Only 1 of 2 trustworthy copies of sha1foo exist.-  Back it up with git-annex copy.-  Bad file size; moved to /Users/jtang/develop/git-annex/.t/tmprepo/.git/annex/bad/WORM:1297565141:20:foo-  Bad file content; moved to /Users/jtang/develop/git-annex/.t/tmprepo/.git/annex/bad/SHA1:ee80d2cec57a3810db83b80e1b320df3a3721ffa-Testing 1:blackbox:12:git-annex fsck:1                                        -### Failure in: 1:blackbox:12:git-annex fsck:1-fsck failed to fail with content only available in untrusted (current) repository-Testing 1:blackbox:12:git-annex fsck:2                                        -Cases: 30  Tried: 26  Errors: 0  Failures: 3  Only 1 of 2 trustworthy copies of foo exist.-  Back it up with git-annex copy.-  The following untrusted locations may also have copies: -  	58e831c2-371b-11e0-bc1f-47d738dc52ee  -- test repo-  Only 1 of 2 trustworthy copies of sha1foo exist.-  Back it up with git-annex copy.-  The following untrusted locations may also have copies: -  	58e831c2-371b-11e0-bc1f-47d738dc52ee  -- test repo-Testing 1:blackbox:13:git-annex migrate:0                                     -Cases: 30  Tried: 27  Errors: 0  Failures: 3  git-annex: user error (Error in fork: forkProcess: resource exhausted (Resource temporarily unavailable))-### Failure in: 1:blackbox:13:git-annex migrate:0-migrate annexedfile failed-Testing 1:blackbox:13:git-annex migrate:1                                     -### Error in:   1:blackbox:13:git-annex migrate:1-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:14:git-annex unused/dropunused                             -### Error in:   1:blackbox:14:git-annex unused/dropunused-forkProcess: resource exhausted (Resource temporarily unavailable)-Cases: 30  Tried: 30  Errors: 2  Failures: 4-test: failed-</pre>---the number of failures vary as I change the values of the maxprocs, I think I  have narrowed it down to OSX just being stupid with limits thus causing the tests to fail.--"""]]
− doc/bugs/Problems_running_make_on_osx/comment_16_5c2dd6002aadaab30841b77a5f5aed 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 16"- date="2011-02-13T04:52:26Z"- content="""-I've fixed the test suite to not accumulate all those zombie processes. Now only 2 or 3 processes should run max. Am curious to see if that clears up all the problems.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_17_62fccb04b0e4b695312f7a3f32fb96 
@@ -1,43 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 17"- date="2011-02-13T10:46:54Z"- content="""-Yeap, that did the trick. I just tested a few separate OSX 10.6.6 systems and the tests are better behaved now, only 3 failures now.--So the tests behave better (at least we don't get resource fork errors any more)- - * after the commit c319a3 without modifying the system limits (of 266 procs per user)- * without the commit c319a3 and when I increase the system process limits to as much as OSX allows--On all the systems I tested on, I'm down to 3 failures now.--<pre>-### Failure in: 1:blackbox:3:git-annex unannex:1:with content-foo is not a symlink-### Failure in: 1:blackbox:4:git-annex drop:0:no remotes-drop wrongly succeeded with no known copy of file-Cases: 30  Tried: 20  Errors: 0  Failures: 2add foo ok-ok-Cases: 30  Tried: 24  Errors: 0  Failures: 2  Only 1 of 2 trustworthy copies of foo exist.-  Back it up with git-annex copy.-  Only 1 of 2 trustworthy copies of sha1foo exist.-  Back it up with git-annex copy.-  Bad file size; moved to /Users/jtang/develop/git-annex/.t/tmprepo/.git/annex/bad/WORM:1297594011:20:foo-  Bad file content; moved to /Users/jtang/develop/git-annex/.t/tmprepo/.git/annex/bad/SHA1:ee80d2cec57a3810db83b80e1b320df3a3721ffa-### Failure in: 1:blackbox:12:git-annex fsck:1-fsck failed to fail with content only available in untrusted (current) repository-Cases: 30  Tried: 26  Errors: 0  Failures: 3  Only 1 of 2 trustworthy copies of foo exist.-  Back it up with git-annex copy.-  The following untrusted locations may also have copies: -  	90d63906-375e-11e0-8867-abb8a6368269  -- test repo-  Only 1 of 2 trustworthy copies of sha1foo exist.-  Back it up with git-annex copy.-  The following untrusted locations may also have copies: -  	90d63906-375e-11e0-8867-abb8a6368269  -- test repo-Cases: 30  Tried: 30  Errors: 0  Failures: 3-</pre>--It's the same set of failures across all the OSX systems that I have tested on. Now I just need to figure out why there are still these three failures.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_18_64fab50d95de619eb2e8f08f90237d 
@@ -1,24 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="maybe killed another osx bug in the test."- date="2011-02-13T15:12:10Z"- content="""-I think I have figured out why --    ### Failure in: 1:blackbox:3:git-annex unannex:1:with content-    foo is not a symlink--It goes back to the this piece of code (in test.hs)--    copyrepo :: FilePath -> FilePath -> IO FilePath-    copyrepo old new = do-            cleanup new-            ensuretmpdir-            Utility.boolSystem \"cp\" [\"-pr\", old, new] @? \"cp -pr failed\"--It seems that on OSX it does not preserve the symbolic link information, basically cp is not gnu cp on OSX, doing a \"cp -a SOURCE DEST\" seem's to the right thing on OSX. I tried it out on my archlinux workstation by replacing *-pr* with just *-a* and all the tests passed on archlinux.--I'm not sure what the implications would be with changing the test with changing the cp command.--"""]]
− doc/bugs/Problems_running_make_on_osx/comment_19_4253988ed178054c8b6400beeed68a 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 19"- date="2011-02-13T15:55:47Z"- content="""-On second thought and after some messing (trying most of the options and combinations of options on OSX for).... I tried replacing cp with gnu cp from coreutils on my OSX install, and all the tests passed. *sigh* cp -a is preserving some permissions and attributes but not all, its not behaving in the same way as the gnu cp does... the closet thing that I have found on OSX that behaves in the same way as gnu \"cp -pr\" is to use \"ditto\".--Just doing a \"ditto SOURCE DEST\" in the tests passes everything. I'm not sure if its a good idea to use this even though it works. Though this is just the tests, does it affect CopyFile.hs where \"cp\" is called?--"""]]
− doc/bugs/Problems_running_make_on_osx/comment_1_34120e82331ace01a6a4960862d38f2 
@@ -1,17 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawmd3qri1pXEYktlxYGwj37wCnrM4FMEJCc"- nickname="Antoine"- subject="Got it going!"- date="2011-02-06T06:02:57Z"- content="""-Thanks to your feedback, I got it going.  --Maybe those two should be added to the 'OSX how-to' in the forum   --[realizes pcre-light is needed but pcre not installed on my mac]  -sudo port install pcre  -sudo cabal install pcre-light  --[tests are failing, need haskell's quickcheck]  -sudo cabal install quickcheck  -"""]]
− doc/bugs/Problems_running_make_on_osx/comment_20_7db27d1a22666c831848bc6c06d66a 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 20"- date="2011-02-13T17:54:09Z"- content="""-Outside the test suite, git-annex's actual use of cp puts fairly low demands on it. It tries to use cp -a or cp -p if available just to preserve whatever attributes it can preserve, but the worst case if that you have a symlink pointing to a file that doesn't have the original timestamp or whatever. And there's little expectation git preserves that stuff anyway.--I will probably try to make the test suite entirely use git clone rather than cp.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_2_cc53d1681d576186dbc868dd9801d55 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-02-06T17:39:52Z"- content="""-Yes, I've moved it to [[install/OSX]] page where anyone can update it in this wiki, and added your improvements.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_3_68f0f8ae953589ae26d57310b40c878 
@@ -1,57 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="tests fail with more recent installs of haskell platform"- date="2011-02-07T12:43:43Z"- content="""-I'm running ghc 6.12.3 with the corresponding haskell-platform package from the HP site which I installed in preference to the macports version of haskell-platform (it's quite old). it seems when you install quickcheck, the version that is installed is of version 2.4.0.1 and not 1.2.0 which git-annex depends on for its tests.--<pre>-jtang@x00:~ $ cabal install quickcheck --reinstall               -Resolving dependencies...-Configuring QuickCheck-2.4.0.1...-Preprocessing library QuickCheck-2.4.0.1...--..-and so on..-..--</pre>--it fails with this--<pre>-[54 of 54] Compiling Main             ( test.hs, test.o )--test.hs:56:3:-    No instance for (QuickCheck-1.2.0.1:Test.QuickCheck.Arbitrary Char)-      arising from a use of `qctest' at test.hs:56:3-64-    Possible fix:-      add an instance declaration for-      (QuickCheck-1.2.0.1:Test.QuickCheck.Arbitrary Char)-    In the expression:-        qctest \"prop_idempotent_deencode\" Git.prop_idempotent_deencode-    In the first argument of `TestList', namely-        `[qctest \"prop_idempotent_deencode\" Git.prop_idempotent_deencode,-          qctest \"prop_idempotent_fileKey\" Locations.prop_idempotent_fileKey,-          qctest-            \"prop_idempotent_key_read_show\"-            BackendTypes.prop_idempotent_key_read_show,-          qctest-            \"prop_idempotent_shellEscape\" Utility.prop_idempotent_shellEscape,-          ....]'-    In the second argument of `($)', namely-        `TestList-           [qctest \"prop_idempotent_deencode\" Git.prop_idempotent_deencode,-            qctest \"prop_idempotent_fileKey\" Locations.prop_idempotent_fileKey,-            qctest-              \"prop_idempotent_key_read_show\"-              BackendTypes.prop_idempotent_key_read_show,-            qctest-              \"prop_idempotent_shellEscape\" Utility.prop_idempotent_shellEscape,-            ....]'-</pre>--I'd imagine if I could downgrade, it would compile and pass the tests (I hope)--"""]]
− doc/bugs/Problems_running_make_on_osx/comment_4_c52be386f79f14c8570a8f1397c6858 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-02-08T19:00:14Z"- content="""-I doubt that git-annex can be used with QuickCheck 1.2.0. The QuickCheck I've tested it with is 2.1.0.3 actually.--I suspect you have an old version of the TestPack haskell library on your system, that is linked against QuickCheck 1.2.0. Git-annex has been tested with TestPack 2.0.0, which uses QuickCheck 2.x.--In any case, you don't have to run 'make test' to build git-annex, and my comments above should make the main program compile, I expect.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_5_7f1330a1e541b0f3e2192e596d7f7be 
@@ -1,107 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 5"- date="2011-02-08T19:56:55Z"- content="""-Ah, that gave me a good clue, my system just got pretty confused with a mixture of quickcheck and testpack installs. Would it be possible to put up a list of versions of the software you are using on your development environment? (at least the minimum tested version) --I guess it shouldn't matter to most users who are going to rely on packagers to sort these dependancy issues, but it's nice to know. --Anyway, the tests build now, and they seem to fail on my (rather messy) install of haskell platform + ghc 6.12 on osx 10.6.6.--<pre>-< output that passed some tests >-Testing 1:blackbox:0:git-annex init-Testing 1:blackbox:1:git-annex add:0-Testing 1:blackbox:1:git-annex add:1-Cases: 30  Tried: 9  Errors: 0  Failures: 0test: sha1sum: executeFile: does not exist (No such file or directory)-  git-annex: <file descriptor: 6>: hGetLine: end of file-### Failure in: 1:blackbox:1:git-annex add:1-add with SHA1 failed-Testing 1:blackbox:2:git-annex setkey/fromkey-Cases: 30  Tried: 10  Errors: 0  Failures: 1(checksum...) test: sha1sum: executeFile: does not exist (No such file or directory)-### Error in:   1:blackbox:2:git-annex setkey/fromkey-<file descriptor: 3>: hGetLine: end of file-Testing 1:blackbox:3:git-annex unannex:0:no content-Cases: 30  Tried: 11  Errors: 1  Failures: 1chmod: -R: No such file or directory-chmod: -R: No such file or directory-Testing 1:blackbox:3:git-annex unannex:1:with content-### Failure in: 1:blackbox:3:git-annex unannex:1:with content-foo is not a symlink-Testing 1:blackbox:4:git-annex drop:0:no remotes-Cases: 30  Tried: 13  Errors: 1  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:4:git-annex drop:0:no remotes-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:4:git-annex drop:1:with remote-Cases: 30  Tried: 14  Errors: 2  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:4:git-annex drop:1:with remote-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:4:git-annex drop:2:untrusted remote-Cases: 30  Tried: 15  Errors: 3  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:4:git-annex drop:2:untrusted remote-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:5:git-annex get-Cases: 30  Tried: 16  Errors: 4  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:5:git-annex get-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:6:git-annex move-Cases: 30  Tried: 17  Errors: 5  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:6:git-annex move-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:7:git-annex copy-Cases: 30  Tried: 18  Errors: 6  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:7:git-annex copy-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:8:git-annex unlock/lock-Cases: 30  Tried: 19  Errors: 7  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:8:git-annex unlock/lock-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:9:git-annex edit/commit:0-Cases: 30  Tried: 20  Errors: 8  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:9:git-annex edit/commit:0-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:9:git-annex edit/commit:1-Cases: 30  Tried: 21  Errors: 9  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:9:git-annex edit/commit:1-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:10:git-annex fix-Cases: 30  Tried: 22  Errors: 10  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:10:git-annex fix-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:11:git-annex trust/untrust/semitrust-Cases: 30  Tried: 23  Errors: 11  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:11:git-annex trust/untrust/semitrust-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:12:git-annex fsck:0-Cases: 30  Tried: 24  Errors: 12  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:12:git-annex fsck:0-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:12:git-annex fsck:1-Cases: 30  Tried: 25  Errors: 13  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:12:git-annex fsck:1-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:12:git-annex fsck:2-Cases: 30  Tried: 26  Errors: 14  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:12:git-annex fsck:2-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:13:git-annex migrate:0-Cases: 30  Tried: 27  Errors: 15  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:13:git-annex migrate:0-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:13:git-annex migrate:1-Cases: 30  Tried: 28  Errors: 16  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:13:git-annex migrate:1-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Testing 1:blackbox:14:git-annex unused/dropunused-Cases: 30  Tried: 29  Errors: 17  Failures: 2chmod: -R: No such file or directory-### Error in:   1:blackbox:14:git-annex unused/dropunused-.t/tmprepo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-Cases: 30  Tried: 30  Errors: 18  Failures: 2-chmod: -R: No such file or directory-test: .t/repo/.git/annex/objects/WORM:1297194705:20:foo/WORM:1297194705:20:foo: removeLink: permission denied (Permission denied)-make: *** [test] Error 1-</pre>--I assumed that since the tests built, then running them shouldn't be a problem. It looks like some argument isn't being passed about for the location of the .t directory that gets created. I will check the dependancies on my system again.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_6_0c46f5165ceb5a7b9ea9689c33b3a4f 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 6"- date="2011-02-08T23:20:08Z"- content="""-You're missing the sha1sum command, everything else is a followon error from that. Added a hint about this to [[install]],-and in the next version configure will check for sha1sum.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_7_237a137cce58a28abcc736cbf2c420b 
@@ -1,22 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 7"- date="2011-02-09T00:45:31Z"- content="""-That's odd, I have the md5sha1sum package installed and it still fails with pretty much the same error--<pre>-Testing 1:blackbox:0:git-annex init-Cases: 30  Tried: 7  Errors: 0  Failures: 0chmod: -R: No such file or directory-### Error in:   1:blackbox:0:git-annex init-.t/repo/.git/annex/objects/SHA1:ee80d2cec57a3810db83b80e1b320df3a3721ffa/SHA1:ee80d2cec57a3810db83b80e1b320df3a3721ffa: removeLink: permission denied (Permission denied)-Testing 1:blackbox:1:git-annex add:0-### Error in:   1:blackbox:1:git-annex add:0-foo: openFile: permission denied (Permission denied)--< and so on >-</pre>--the configure script finds sha1sum, builds and starts to run.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_8_efafa203addf8fa79e33e21a87fb5a2 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 8"- date="2011-02-09T04:10:27Z"- content="""-The chmod errors are because your chmod does not understand the -R argument. Only the test suite uses chmod -R. I've fixed it to modify modes manually.-"""]]
− doc/bugs/Problems_running_make_on_osx/comment_9_cc283b485b3c95ba7eebc8f0c96969b 
@@ -1,66 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 9"- date="2011-02-09T09:12:52Z"- content="""-[a0826293][] fixed the last problem, there is coreutils available in macports, if they are installed you get the gnu equivalents but they are prefixed with a g (e.g. gchmod instead of chmod), I guess not everyone will have these install or prefer these on [[install/OSX]]--Some more tests fail now...--<pre>-Testing 1:blackbox:3:git-annex unannex:1:with content-### Failure in: 1:blackbox:3:git-annex unannex:1:with content-foo is not a symlink-Testing 1:blackbox:4:git-annex drop:0:no remotes-### Failure in: 1:blackbox:4:git-annex drop:0:no remotes-drop wrongly succeeded with no known copy of file-Testing 1:blackbox:4:git-annex drop:1:with remote-Testing 1:blackbox:4:git-annex drop:2:untrusted remote-Testing 1:blackbox:5:git-annex get-Testing 1:blackbox:6:git-annex move-Testing 1:blackbox:7:git-annex copy-### Failure in: 1:blackbox:7:git-annex copy-move --to of file already there failed-Testing 1:blackbox:8:git-annex unlock/lock-### Error in:   1:blackbox:8:git-annex unlock/lock-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:9:git-annex edit/commit:0-### Error in:   1:blackbox:9:git-annex edit/commit:0-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:9:git-annex edit/commit:1-### Error in:   1:blackbox:9:git-annex edit/commit:1-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:10:git-annex fix-### Error in:   1:blackbox:10:git-annex fix-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:11:git-annex trust/untrust/semitrust-### Error in:   1:blackbox:11:git-annex trust/untrust/semitrust-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:12:git-annex fsck:0-### Error in:   1:blackbox:12:git-annex fsck:0-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:12:git-annex fsck:1-### Error in:   1:blackbox:12:git-annex fsck:1-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:12:git-annex fsck:2-### Error in:   1:blackbox:12:git-annex fsck:2-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:13:git-annex migrate:0-### Error in:   1:blackbox:13:git-annex migrate:0-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:13:git-annex migrate:1-### Error in:   1:blackbox:13:git-annex migrate:1-forkProcess: resource exhausted (Resource temporarily unavailable)-Testing 1:blackbox:14:git-annex unused/dropunused-### Error in:   1:blackbox:14:git-annex unused/dropunused-forkProcess: resource exhausted (Resource temporarily unavailable)-Cases: 30  Tried: 30  Errors: 11  Failures: 3-test: failed-make: *** [test] Error 1-</pre>--On a side note, I think I found another bug in the testing. I had tested in a virtual machine in archlinux (a very recent updated version) Please see the report here [[tests fail when there is no global .gitconfig for the user]]--[a0826293]: http://git.kitenet.net/?p=git-annex;a=commit;h=7a0826293e0ac6c0000f49a1618c1c613b909aa1-"""]]
− doc/bugs/__39__annex_add__39___fails_to___39__git_add__39___for_parent_relative 
@@ -1,15 +0,0 @@-The following commands show the failure:--$ mkdir d && touch d/f--$ mkdir g && cd g && git annex add ../d/f --add ... ok--error: Invalid path '.git/annex/objects/Jx/...--...--Then it seems it is enough to 'git add ../d/f' to complete the operation.--> Thanks for reporting, [[fixed|done]] --[[Joey]]
− doc/bugs/conflicting_haskell_packages/comment_1_e552a6cc6d7d1882e14130edfc2d6b3 
@@ -1,24 +0,0 @@-[[!comment format=mdwn- username="http://ertai.myopenid.com/"- nickname="npouillard"- subject="how to reproduce the package conflict issue"- date="2011-02-07T14:12:43Z"- content="""-If you install the monads-fd package (with cabal install for instance), then you can no longer build git-annex:--<pre>-./configure-  checking cp -a... yes-  checking cp -p... yes-  checking cp --reflink=auto... yes-  checking uuid generator... uuid-  checking xargs -0... yes-  checking rsync... yes-ghc -O2 -Wall --make git-annex--Annex.hs:22:7:-    Ambiguous module name `Control.Monad.State':-      it was found in multiple packages: monads-fd-0.2.0.0 mtl-2.0.1.0-make: *** [git-annex] Error 1-</pre>-"""]]
− doc/bugs/conq:_invalid_command_syntax/comment_1_f33b83025ce974e496f83f248275a66 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-01-03T00:34:59Z"- content="""-AFAICs, you probably just have a \"conq\" program that is running in the background and emitted this error.--The error message is not part of git-annex; it does not run any \"conq\" thing itself. Although you could try passing the --debug parameter to check the commands it does run to see if one of them somehow causes this conq thing.-"""]]
− doc/bugs/conq:_invalid_command_syntax/comment_2_195106ca8dedad5f4d755f625e38e8a 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2012-01-03T00:41:08Z"- content="""-A google search <http://www.google.com/search?hl=en&sclient=psy-ab&q=conq%3A+invalid+command+syntax&btnG=>-finds other examples of this error message related to ssh, mercurial, and bitbucket. What that has to do with git is anyone's guess, but I'm pretty sure git-annex is not related to it at all.-"""]]
− doc/bugs/conq:_invalid_command_syntax/comment_3_55af43e2f43a4c373f7a0a33678d0b1 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://a-or-b.myopenid.com/"- ip="203.45.2.230"- subject="comment 3"- date="2012-01-03T00:49:41Z"- content="""-Yeah,  I saw those google links myself, but couldn't see why the bitbucket/ssh would be relevant.--The strange thing is that I *only* get this message when running git-annex.--I also don't have a conq in my path so I don't know where it is running from.- --Oh well, if I ever sort it out I'll post back here.-"""]]
− doc/bugs/copy_doesn__39__t_scale/comment_1_7c12499c9ac28a9883c029f8c659eb57._co 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX4"- nickname="Lauri"- subject="comment 1"- date="2012-01-28T00:17:37Z"- content="""-To me it very much seems that a commit per file is indeed created at the remote end, although not at the local end. See the following transcript: <https://gist.github.com/1691714>.---"""]]
− doc/bugs/copy_doesn__39__t_scale/comment_2_f85d8023cdbc203bb439644cf7245d4e._co 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2012-01-28T19:32:36Z"- content="""-Ah, I see, I was not thinking about the location log update that's done on the remote side.--For transfers over ssh, that's a separate git-annex-shell invoked per change. For local-local transfers, it's all done in a single process but it spins up a state to handle the remote and then immediately shuts it down, also generating a commit.--In either case, I think there is a nice fix. Since git-annex *does* have a journal nowadays, and goes to all the bother to-support recovery if a process was interrupted and journalled changes that did not get committed, there's really no reason in either of these cases for the remote end to do anything more than journal the change. The next time git-annex is actually run on the remote, and needs to look up location information, it will merge the journalled changes into the branch, in a single commit.--My only real concern is that some remotes might *never* have git-annex run in them directly, and would just continue to accumulate journal files forever. Although due to the way the journal is structured, it can have, at a maximum, the number of files in the git-annex branch. However, the number of files in it is expected to be relatively smal and it might get a trifle innefficient, as it lacks directory hashing. These performance problems could certainly be dealt with if they do turn out to be a problem.-"""]]
− doc/bugs/copy_doesn__39__t_scale/comment_3_4592765c3d77bb5664b8d16867e9d79c._co 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX4"- nickname="Lauri"- subject="comment 3"- date="2012-01-29T01:51:35Z"- content="""-That sounds just fine, but indeed my use case was a bare backup/transfer repository that is meant to always be only at the remote end of git-annex operations. So why not as well do a single commit after everything has been copied and journaled? That's what's done at the other end too, after all. Or, if commits are to be minimized, just stage the journal into the index before finishing, but don't commit it yet?--(I would actually prefer this mode of usage for other git-annex operations, too. In git you can add stuff little by little and commit them all in one go. In git-annex the add immediately creates a commit, which is unexpected and a bit annoying.)--"""]]
− doc/bugs/fails_to_handle_lot_of_files/comment_1_09d8e4e66d8273fab611bd29e82dc7f 
@@ -1,8 +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-10-26T17:16:52Z"- content="""-After another run, i am at 8909 files in the remote, now.-"""]]
− doc/bugs/fails_to_handle_lot_of_files/comment_2_fd2ec05f4b5a7a6ae6bd9f5dbc3156d 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 2"- date="2011-10-26T18:22:34Z"- content="""-In case this matters, I just realized that this disk has been formatted with NTFS instead of a sane FS.-"""]]
− doc/bugs/free_space_checking/comment_1_a868e805be43c5a7c19c41f1af8e41e6._commen 
@@ -1,10 +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-03-15T14:11:27Z"- content="""-Keep in mind that lots of small files may have significant overhead, so a warning that it's not possible to make sure there's enough space would make sense for certain corner cases. Actually finding out the exact overhead is beyond git-annex' scope and, given transparent compression etc, ability, but a warning, optionally with a \"do you want to continue\" prompt can't hurt.---- RichiH-"""]]
− doc/bugs/free_space_checking/comment_2_8a65f6d3dcf5baa3f7f2dbe1346e2615._commen 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-03-16T03:04:50Z"- content="""-Right. You probably don't want git-annex to fill up your entire drive anyway, so if it tries to reseve 10 mb or 1% or whatever (probably configurable) for overhead, that should be good enough.-"""]]
− doc/bugs/free_space_checking/comment_3_0fc6ff79a357b1619d13018ccacc7c10._commen 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 3"- date="2011-03-16T15:40:56Z"- content="""-Sometimes, I might want to fill up the disk as much as possible. Thus, a warning is preferable to erroring out too early, imo -- Richard-"""]]
− doc/bugs/fsck__47__fix_should_check__47__fix_the_permissions_of_.git__47__annex 
@@ -1,8 +0,0 @@-git annex carefully setup restrictive permissions of .git/annex directories and files.--The fsck command should check that they are still correct.-The fix command should fix them.--PS: Thanks for this nice tool!--> Good idea, [[done]] (actually, fsck just fixes them too)! --[[Joey]]
− doc/bugs/fsck_claims_failed_checksum_when_less_copies_than_required_are_found.m 
@@ -1,57 +0,0 @@-    (checksum...) failed-    fsck foo (fixing location log) -      Only 1 of 2 trustworthy copies exist of foo-      Back it up with git-annex copy.--> You've given me severely partial output, and no test case, but until-> it says "fsck foo", the output is pertaining to some other file than foo.-> As far as I can see, there is no bug here. --[[Joey]]-->> Sorry, I thought it would be obvious, but that's no excuse for not->> providing additional explanation. The problem is that fsck tells me a->> file's fsck has failed without printing extra details. In this case, the->> checksum is OK while I don't have enough copies to satisfy the fsck. The->> fact that I don't have enough copies is obviously relevant, but I would->> still like to know if the checksums are OK. -- Richard-->>> I think you're misreading the truncated output you posted. The actual,->>> full output would make much more sense. --[[Joey]]-->>>> No. I have a total of 14908 annex keys, 3333 of which are on a remote. The only message other than 'checksum OK' and the above is 'git-annex: 11577 failed'.->>>> I checked several files manually, their checksums are OK so `git annex->>>> fsck` is reporting those files as completely failed when they "only" miss copies. -- Richard-->>>>> fsck considers not enough copies to be a failure condition; it prints->>>>> error messages about it etc. That has nothing to do with checksums.->>>>> --[[Joey]]-->>>>>> I get that. Still, I think it would be _extremely_ useful to know what failures occurred, exactly. Not having enough copies is Not Good, yet not having enough copies and a locally correct file is _lot_ better than having not enough copies and a broken file. I.e. I would prefer:--    (checksum...) OK-    Not enough copies: Only 1 of 2 trustworthy copies exist of foo-->>>>>> or similar and at the end--    git-annex: 0 wrong checksums-    git-annex: 11577 with too few copies-->>>>>> In the end, it comes down to the distinction of different failure classes. -- Richard-->>>>>>> For the third, and final time: ->>>>>>> # You are misreading the truncated output you posted->>>>>>> The "checksum" line is regarding **different** file than the ->>>>>>> not enough copies message. fsck does not attempt to checksum a file->>>>>>> that is not present. [[done]] --[[Joey]]--->>>>>>>> I realized early on that I pasted the wrong cross-passage, but as there is a ton of the same output, I didn't think it would matter. I wasn't aware that it does not try to checksum when there aren't enough copies. To be fair, you only just mentioned that.->>>>>>>> Personally, I think that's a bug as it makes ensuring local correctness before copying a file to remotes impossible.->>>>>>>> Either way, I really didn't know it actually _skipped_ checksumming; that part was missing.->>>>>>>> For the benefit of anyone else who might read this, this is the correct order:--    fsck foo (fixing location log) -      Only 1 of 2 trustworthy copies exist of foo-      Back it up with git-annex copy.-    (checksum...) failed-->>>>>>>> If you would like to keep things this way, fine. I think it's less than ideal, but I don't want to argue, either. -- Richard
− doc/bugs/git_command_line_constructed_by_unannex_command_has_tons_of_redundant_ 
@@ -1,15 +0,0 @@-This doesn't look right:--    simons   11148  0.0  0.0  15572  1268 pts/1    SN+  04:00   0:00              |               \_ git annex unannex stuff-    simons   11150  0.5  0.0 130504 11212 pts/1    SN+  04:00   3:40              |               |   \_ git-annex unannex stuff-    simons   11152  0.0  0.1  39536 23932 pts/1    SN+  04:00   0:00              |               |       \_ git --git-dir=/home/simons/annex/.git --work-tree=/home/simons/annex ls-files --cached -z -- stuff-    simons   11288  0.0  0.0      0     0 pts/1    ZN+  04:01   0:00              |               |       \_ [git] <defunct>-    simons   11339  0.0  0.0      0     0 pts/1    ZN+  04:02   0:00              |               |       \_ [git-annex] <defunct>-    simons   11442  0.0  0.0      0     0 pts/1    ZN+  04:06   0:00              |               |       \_ [git] <defunct>-    simons   11443  0.0  0.0      0     0 pts/1    ZN+  04:06   0:05              |               |       \_ [git] <defunct>-    simons   16541  0.0  0.0      0     0 pts/1    ZN+  04:14   0:00              |               |       \_ [git] <defunct>-    simons   16543  0.3  0.0  15644  1744 pts/1    SN+  04:14   2:13              |               |       \_ git --git-dir=/home/simons/annex/.git --work-tree=/home/simons/annex cat-file --batch-    simons   14224  0.0  0.0 100744   796 pts/1    SN+  14:10   0:00              |               |       \_ xargs -0 git --git-dir=/home/simons/annex/.git --work-tree=/home/simons/annex commit -a -m content removed from git annex-    simons   14225  0.4  0.1  32684 18652 pts/1    DN+  14:10   0:00              |               |           \_ git --git-dir=/home/simons/annex/.git --work-tree=/home/simons/annex commit -a -m content removed from git annex -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a -a--> [[Fixed|done]] --[[Joey]]
− doc/bugs/git_rename_detection_on_file_move/comment_10_5ec2f965c80cc5dd31ee3c4ed 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"- nickname="Rafael"- subject="comment 10"- date="2012-05-15T07:36:25Z"- content="""-Won't git itself be fixed on this issue? It was on my plans to look into that, however I don't know how difficult it will be.-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_1_0531dcfa833b0321a7009526ef 
@@ -1,26 +0,0 @@-[[!comment format=mdwn- username="http://christian.amsuess.com/chrysn"- nickname="chrysn"- subject="use mini-branches"- date="2011-03-09T23:47:48Z"- content="""-if you go for the two-commits version, small intermediate branches (or git-commit-tree) could be used to create a tree like this:---    *   commit 106eef2-    |\  Merge: 436e46f 9395665-    | | -    | |     the main commit-    | |   -    | * commit 9395665-    |/  -    |       intermediate move-    |  -    * commit 436e46f-    | -    |     ...--while the first commit (436e46f) has a \"`/subdir/foo → ../.git-annex/where_foo_is`\", the intermediate (9395665) has \"`/subdir/deeper/foo → ../.git-annex/where_foo_is`\", and the inal commit (106eef2) has \"`/subdir/deeper/foo → ../../.git-annex/where_foo_is`\".--`--follow` uses the intermediate commit to find the history, but the intermediate commit would neither show up in `git log --first-parent` nor affect `git diff HEAD^..` & co. (there could still be confusion over `git show`, though).-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_2_7101d07400ad5935f880dc00d8 
@@ -1,27 +0,0 @@-[[!comment format=mdwn- username="praet"- ip="81.240.159.215"- subject="Use variable symlinks, relative to the repo's root ?"- date="2011-03-10T16:50:28Z"- content="""-It all boils down to the fact that the path to a relative symlink's target is determined relative to the symlink itself.--Now, if we define the symlink's target relative to the git repo's root (eg. using the $GIT_DIR environment variable, which can be a relative or absolute path itself), this unfortunately results in an absolute symlink, which would -for obvious reasons- only be usable locally:--    user@host:~$ mkdir -p tmp/{.git/annex,somefolder}-    user@host:~$ export GIT_DIR=~/tmp-    user@host:~$ touch $GIT_DIR/.git/annex/realfile-    user@host:~$ ln -s $GIT_DIR/.git/annex/realfile $GIT_DIR/somefolder/file-    user@host:~$ ls -al $GIT_DIR/somefolder/-    total 12-    drwxr-x--- 2 user group 4096 2011-03-10 16:54 .-    drwxr-x--- 4 user group 4096 2011-03-10 16:53 ..-    lrwxrwxrwx 1 user group   33 2011-03-10 16:54 file -> /home/user/tmp/.git/annex/realfile-    user@host:~$--So, what we need is the ability to record the actual variable name (instead of it's value) in our symlinks.--It *is* possible, using [variable/variant symlinks](http://en.wikipedia.org/wiki/Symbolic_link#Variable_symbolic_links), yet I'm unsure as to whether or not this is available on Linux systems, and even if it is, it would introduce compatibility issues in multi-OS environments.--Thoughts on this?-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_3_57010bcaca42089b451ad8659a 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-03-16T03:03:19Z"- content="""-Interesting, I had not heard of variable symlinks before. AFAIK linux does not have them.-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_4_79d96599f757757f34d7b784e6 
@@ -1,34 +0,0 @@-[[!comment format=mdwn- username="praet"- ip="81.240.27.89"- subject="Brainfart"- date="2011-03-20T20:11:27Z"- content="""-Haven't given these any serious thought (which will become apparent in a moment) but hoping they will give birth to some less retarded ideas:-------### Bait'n'switch--- pre-commit: Replace all staged symlinks (when pointing to annexed files) with plaintext files containing the key of their respective annexed content, re-stage, and add their paths (relative to repo root) to .gitignore.-- post-commit: Replace the plaintext files with (git annex fix'ed) symlinks.--In doing so, the blobs to be committed can remain unaltered, irrespective of their related files' depth in the directory hierarchy.--To prevent git from reporting ALL annexed files as unstaged changes after running post-commit hook, their paths would need to be added to .gitignore.--This wouldn't cause any issues when adding files, very little when modifying files (would need some alterations to \"git annex unlock\"), BUT would make git totally oblivious to removals...-------### Manifest-based (re)population-- Keep a manifest of all annexed files (key + relative path)-- DON'T track the symlinks (.gitignore)-- Populate/update the directory structure using a post-commit hook.--... thus circumventing the issue entirely, yet diffstats (et al.) would be rather uninformative.-------***Wide open to suggestions, criticism, mocking laughter and finger-pointing :)***-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1db 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="praet"- ip="81.242.56.203"- subject="comment 5"- date="2011-03-21T19:58:34Z"- content="""-In the meantime, would it be acceptable to split the pre-commit hook-into two discrete parts?--This would allow to (if preferred) defer \"git annex fix\" until-post-commit while still keeping the safety net for unlocked files.-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_6_f63de6fe2f7189c8c2908cc41c 
@@ -1,19 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="extra level of indirection"- date="2011-12-19T12:45:18Z"- content="""-Surely this could be handled with an extra layer of indirection?--git-annex would ensure that every directory containing annexed data contains a new symlink `.git-annex` which points to `$git_root/.git/annex`.  Then every symlink to an annexed object uses a relative symlink via this: `.git_annex/objects/xx/yy/ZZZZZZZZZZ`.  Even though this symlink is relative, moving it to a different directory would not break anything: if the move destination directory already contained other annexed data, it would also already contain `.git-annex` so git-annex wouldn't need to do anything.  And if it didn't, git-annex would simply create a new `.git-annex` symlink there.--These `.git-annex` symlinks could either be added to `.gitignore`, or manually/automatically checked in to the current branch - I'm not sure which would be best.  There's also the option of using multiple levels of indirection:--    foo/bar/baz/.git-annex -> ../.git-annex-    foo/bar/.git-annex -> ../.git-annex-    foo/.git-annex -> ../.git-annex-    .git-annex -> .git/annex--I'm not sure whether this would bring any advantages.  It might bring a performance hit due to the kernel having to traverse more symlinks, but without benchmarking it's difficult to say how much.  I'd expect it only to be an issue with a large number of deep directory trees.-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_7_7f20d0b2f6ed1c34021a135438 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 7"- date="2011-12-19T18:22:25Z"- content="""-That seems an excellent idea, also eliminating the need for git annex fix after moving. --However, I think CVS and svn have taught us the pain associated with a version control system putting something in every subdirectory. Would this pain be worth avoiding the minor pain of needing git annex fix and sometimes being unable to follow renames?-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_8_6a00500b24ba53248c78e1ffc8 
@@ -1,21 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="comment 8"- date="2011-12-20T12:00:11Z"- content="""-Personally I'd rather have working rename detection but I agree it's not 100% ideal to be littering multiple directories like this, so perhaps you could make it optional, e.g. based on a git config setting?--Here are a few more considerations, some in defence of the approach, some against it:--* `.git-annex` is hidden; `CVS/` is not.-* Unlike `CVS/` and `.svn/`, it's only a symlink, not a directory containing other files.-* It doesn't contain any data specific to that directory and could easily be regenerated if deleted accidentally or otherwise.-* If a whole directory containing `.git-annex` was moved within the repository:-    * git-annex would need to fix up these symlinks if and only if it's moved to a different depth within the tree.-    * However, if the multi-level indirection approach is used, `.git-annex` in any subdirectory is *always* a symlink to `../.git-annex` so instead you would need to check that all of the new ancestors contain this symlink too, and optionally remove any no longer needed symlinks.-    * In either case, git-annex already goes to the trouble of fixing symlinks, and if anything, I *think* this approach would reduce the number of symlinks which need checking (right?)-* find `$git_root/foo -follow`, `diff -r` etc. would traverse into `$git_root/.git/annex`--This last point is the only downside to this approach I can think of which gives me any noticeable cause for concern.  However, people are already use to working around this from CVS and svn days, e.g. `diff -r -x .svn` so I don't think it's anywhere near bad enough to rule it out.-"""]]
− doc/bugs/git_rename_detection_on_file_move/comment_9_75e0973f6d573df615e01005eb 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 9"- date="2011-12-20T14:56:12Z"- content="""-Git can follow the rename fine if the file is committed before `git annex fix` (you can git commit -n to see this), so -making git-annex pre-commit generate a fixup commit before the staged commit would be one way. Or the other two ways I originally mentioned when writing down this minor issue. I like all those approaches better than .git-annex clutter.-"""]]
− doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_1_5f60006c9bb095167d817f234 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-07-04T22:58:46Z"- content="""-Well if it happens again why don't you use `ps` or `strace` to see what it's doing.-"""]]
− doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_2_cd0123392b16d89db41b45464 
@@ -1,23 +0,0 @@-[[!comment format=mdwn- username="https://lithitux.org/openidserver/users/pavel"- nickname="pavel"- subject="&quot;Me too&quot;"- date="2011-07-05T15:54:19Z"- content="""-I've also seen this apparent hang during upgrade to v3. A few more details:--The annex in question has just under 18k files (and hence that many log files), which can slow down directory operations when they're all in the same place (like, for example, .git/annex/journal).--git-annex uses virtually no CPU time and disk IO when it's hanging like this; the first time it happened, 'ps' showed three defunct git processes, with two \"git-annex\" processes and three \"git\" procs:-- * git --git-dir=/mnt/annex/.git --work-tree=/mnt/annex cat-file --batch- * git --git-dir=/mnt/annex/.git --work-tree=/mnt/annex hash-object -w --stdin-paths- * git --git-dir=/mnt/annex/.git --work-tree=/mnt/annex update-index -z --index-info--I Ctrl+C'd that and tried again, but it hung again -- this time without the defunct gits.--An strace of the process and its children at the time of hang can be found at http://pastebin.com/4kNh4zEJ . It showed somewhat weird behaviour: When I attached with strace, it would scroll through a whole bunch of syscalls making up the open-fstat-read-close-write loop on .git/annex/journal files, but then would block on a write (sorry, don't have that in my scrollback any more so can't give more details) until I Ctrl+C'd strace; when attaching again, it would again scroll through the syscalls for a second or so and then hang with no output.--Ultimately I detached/reattached with strace about two dozen times and that caused it (?) to finish the upgrade; not really sure how to explain it, but it seems like too much of a timing coincidence.--"""]]
− doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_3_86d9e7244ae492bcbe62720b8 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-07-05T17:31:22Z"- content="""-I've seen this kind of piping stall that is unblocked by strace before. It can vary with versions of GHC, so it would be good to know what version built git-annex (and on what OS version). I filed a bug report upstream before at <http://bugs.debian.org/624389>.--I really need a full strace -f from the top, or at least a complete `strace -o log` of git-annex from one hang through to another hang. The strace you pastebinned does not seem complete. If I can work out which specific git command is being written to when it hangs I can lift the writing out into a separate thread or process to fix it.--@pavel, you mentioned three defunct git processes, and then showed ps output for 3 git processes. Were there 6 git processes in total? And then when you ran it again you said there were no defunct gits -- where the other 3 git processes running once again?--As best I can make out from the (apparently) running git processes, it seems like the journal files for the upgrade had all been written, and the hang occurred when staging them all into the index in preparation for a commit. I have committed a change that lifts the code that does that write out into a new process, which, if I am guessing right on the limited info I have, will avoid the hang.--However, since I can't reproduce it, even when I put 200 thousand files in the journal and have git-annex process them, I can't be sure.-"""]]
− doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_4_91439d4dbbf1461e281b276eb 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-07-05T18:37:21Z"- content="""-I've managed to reproduce this and confirmed my fix works.-"""]]
− doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_5_ca33a9ca0df33f7c1b58353d7 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 5"- date="2011-07-05T19:06:48Z"- content="""-By the way, the original bug reporter mentioned deleting .git/annex/journal. This is not recommended, and doing it during an upgrade can result in git-annex losing location tracking information. You should probably run `git annex fsck` or reset to the old git tree (and `git config annex.version 2`) and upgrade again.-"""]]
− doc/bugs/problem_with_upgrade_v2_-__62___v3/comment_6_f360f0006bc9115bc5a3e2eb9 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://lithitux.org/openidserver/users/pavel"- nickname="pavel"- subject="comment 6"- date="2011-07-06T08:14:26Z"- content="""-Ah, great, thanks very much for the quick fix!--Yes, when I mentioned three defunct git processes, there were three processes shown as \"git [defunct]\", plus the three git processes I listed, plus two \"git-annex\" processes. Upon cancel/resume, there were no defunct git processes when I checked, but by the time I found the bug report on the forum and commented I'd already successfully upgraded by annex (by repeatedly attaching strace) and couldn't really easily get at either additional 'ps' info or a fuller strace than what I posted (that was just the log from one of the attach/detach cycles), so it's a relief you managed to pinpoint the problem.-"""]]
− doc/bugs/problems_with_utf8_names/comment_1_3c7e3f021c2c94277eecf9c8af6cec5f._c 
@@ -1,17 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="Any update on this?"- date="2011-12-24T01:05:07Z"- content="""-I just noticed this issue, and was wondering what the current status is.--    % ls -l 04\ -\ Orixás.mp3-    -rw-r--r-- 1 adam users 8377816 Jul 12  2007 04 - Orixás.mp3-    % echo 04\ -\ Orixás.mp3 | od -c-    0000000   0   4       -       O   r   i   x 303 241   s   .   m   p   3-    0000020  \n-    0000021-    % git annex add 04\ -\ Orixás.mp3-    git-annex: /home/adam/music/RotC/transcribe/04 - Orixás.mp3: getSymbolicLinkStatus: does not exist (No such file or directory)-"""]]
− doc/bugs/problems_with_utf8_names/comment_2_bad4c4c5f54358d1bc0ab2adc713782a._c 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 2"- date="2011-12-24T12:49:40Z"- content="""-This (rather longish) thread discusses the current situation, the planned changes for 7.2 and the various issues: http://haskell.org/pipermail/glasgow-haskell-users/2011-November/021115.html--The summary seems to be: From 7.2 on, getDirectoryContents _will_ return proper Strings, i.e. where a Char represents a Unicode code point, and not a Word8, which will fix the problem of outputting them.-"""]]
− doc/bugs/problems_with_utf8_names/comment_3_4f936a5d3f9c7df64c8a87e62b7fbfdc._c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 3"- date="2011-12-24T12:51:43Z"- content="""-An alternative that is available from ghc 7.4 on is a pure ByteString based unix API: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/16556-"""]]
− doc/bugs/problems_with_utf8_names/comment_4_93bee35f5fa7744834994bc7a253a6f9._c 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-12-24T16:49:13Z"- content="""-Adam, this bug was fixed a long time ago, first using option #2 above, but later switching to option #3 -- git-annex treats filenames as opaque binary blobs and never decodes them in any encoding; haskell's normal encoding support for stdio is disabled. --And it never resulted in a failure like you show. I cannot reproduce your problem, but it is a different bug, please open a new bug report.-"""]]
− doc/bugs/problems_with_utf8_names/comment_5_519cda534c7aea7f5ad5acd3f76e21fa._c 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX4"- nickname="Lauri"- subject="comment 5"- date="2012-01-26T22:13:18Z"- content="""-I also encountered Adam's bug. The problem seems to be that communication with the git process is done with `Char8`-bytestrings. So, when `L.unpack` is called, all filenames that git outputs (with `ls-files` or `ls-tree`) are interpreted to be in latin-1, which wreaks havoc if they are really in UTF-8.--I suspect that it would be enough to just switch to standard `String`s (or `Data.Text.Text`) instead of bytestrings for textual data, and to `Word8`-bytestrings for pure binary data. GHC should nowadays handle locale-dependent encoding of `String`s transparently.--"""]]
− doc/bugs/problems_with_utf8_names/comment_6_52e0bfff2b177b6f92e226b25d2f3ff1._c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 6"- date="2012-01-27T21:00:06Z"- content="""-Lauri, what version of GHC do you have that behaves this way? 7.0.4 does not. -"""]]
− doc/bugs/problems_with_utf8_names/comment_7_0cc588f787d6eecfa19a8f6cee4b07b5._c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawk6QAwUsFHpr3Km1yQbg8hf3S7RDYf7hX4"- nickname="Lauri"- subject="comment 7"- date="2012-01-28T00:21:40Z"- content="""-7.2. nomeata already explained the issue. I got utf-8 filenames to work on a utf-8 locale by switching from Char8-bytestrings to UTF8-bytestrings, and adding `hSetEncoding h localeEncoding` to suitable places. Making things work properly with an arbitrary locale encoding would be more complicated.-"""]]
− doc/bugs/problems_with_utf8_names/comment_8_ff5c6da9eadfee20c18c86b648a62c47._c 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 8"- date="2012-01-28T19:40:34Z"- content="""-Lauri a scratch patch would be very helpful. Encoding stuff makes my head explode.--However, I am very worried by haskell's changes WRT unicode and filenames. Based on user input, git-annex users like to use it on diverse sets of files, with diverse and ill-defined encodings. Faffing about with converting between encodings seems likely to speactacularly fail.-"""]]
− doc/bugs/support_bare_git_repo__44___with_the_annex_directory_exposed_to_http.m 
@@ -1,20 +0,0 @@-Let's say that http://people.collabora.com/~alsuren/git/fate-suite.git/ is a bare git repo. It has been 'git update-server-info'd so that it can be served on a dumb http server.--The repo is also a git annex remote, created using the following commands:--* git remote add alsuren git+ssh://people.collabora.co.uk/user/alsuren/public_html/fate-suite.git-* git push alsuren --all-* git annex copy --to=alsuren--so http://people.collabora.com/~alsuren/git/fate-suite.git/annex is a valid git annex (though listing dirs is forbidden, so you need to know the filenames ahead of time).--I would like to be able to use the following commands to get a clone of the repo:--* git clone http://people.collabora.com/~alsuren/git/fate-suite.git/-* cd fate-suite-* git annex get--This would allow contributors to quickly get a copy of our upstream repo and start contributing with minimal bandwidth/effort.--> This is now supported.. I look forward to seeing your project using it!-> --[[Joey]] [[!tag done]]
− doc/bugs/uninit_does_not_work_in_old_repos/comment_1_bc0619c6e17139df74639448aa 
@@ -1,8 +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-10-29T15:30:09Z"- content="""-After upgrading the repo, I still have to commit the changes, else git-annex won't let me uninit. Arguably a Good Thing, but I wanted to document it here.-"""]]
− doc/bugs/wishlist:_allow_users_to_provide_UUID_when_running___96__git_annex_ini 
@@ -1,5 +0,0 @@-As there's no way to permanently hide remotes and I have to recreate two repos now, I would love to be able to re-use the old UUIDs to remove clutter.--> git-annex already provides a way to do this: Copy `.git/config` from the-> original repo (or use `git-config` to set `annex.uuid`) *before* running-> `git annex init`. [[done]] --[[Joey]]
− doc/design/assistant/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._commen 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://launchpad.net/~gdr-go2"- nickname="gdr-go2"- subject="FAT symlinks"- date="2012-05-28T18:12:10Z"- content="""-It's a linux kernel so perhaps another option would be to create a big file and mount -o loop-"""]]
− doc/design/assistant/blog/day_3__more_races/comment_1_d6015338f602b574a3805de54 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkmtR6oVColYKoU0SjBORLDGrwR10G-mKo"- nickname="Jo-Herman"- subject="Dropbox Inotify"- date="2012-06-06T22:03:29Z"- content="""-Actually, Dropbox giver you a warning via libnotify inotify. It tends to go away too quickly to properly read though, much less actually copy down the command...-"""]]
− doc/design/assistant/blog/day_3__more_races/comment_2_4d6b23fc6442e0ee0303523cb 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.252.8.36"- subject="comment 2"- date="2012-06-06T23:25:57Z"- content="""-When I work on the [[webapp]], I'm planning to make it display this warning, and any other similar warning messages that might come up.-"""]]
− doc/design/assistant/blog/day_3__more_races/comment_3_03f5b2344c2a47dea60086f21 
@@ -1,14 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"- nickname="Jim"- subject="Wording"- date="2012-06-07T03:43:19Z"- content="""-For the unfamiliar, it's hard to tell if a command like that would persist.  I'd suggest being as clear as possible, e.g.:--    Increase the limit for now by running:-      sudo sysctl fs.inotify.max_user_watches=81920-    Increase the limit now and automatically at every boot by running:-      echo fs.inotify.max_user_watches=81920 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p--"""]]
− doc/design/assistant/blog/day_3__more_races/comment_4_860e90e989ec022100001c65e 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.252.8.36"- subject="comment 4"- date="2012-06-07T04:48:15Z"- content="""-Good thought Jim. I've done something like that.-"""]]
− doc/design/assistant/blog/day_4__speed/comment_1_bf3c9c33cc0dea5eaeb6f2af110b92 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawldKnauegZulM7X6JoHJs7Gd5PnDjcgx-E"- nickname="Matt"- subject="open source?"- date="2012-06-09T22:34:30Z"- content="""-Are you publishing the source code for git-annex assistant somewhere?-"""]]
− doc/design/assistant/blog/day_4__speed/comment_2_33aba4c9abaa3e6a05a2c87ab7df9d 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.8.126"- subject="comment 2"- date="2012-06-09T23:01:29Z"- content="""-Yes, it's in [[git|download]] with the rest of git-annex. Currently in the `watch` branch.-"""]]
− doc/design/assistant/cloud/comment_1_4997778abc171999499487b71b31c9ba._comment 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkq0-zRhubO6kR9f85-5kALszIzxIokTUw"- nickname="James"- subject="Cloud Service Limitations"- date="2012-06-11T02:15:04Z"- content="""-Hey Joey!--I'm not very tech savvy, but here is my question. -I think for all cloud service providers, there is an upload limitation on how big one file may be.-For example, I can't upload a file bigger than 100 MB on box.net. -Does this affect git-annex at all? Will git-annex automatically split the file depending on the cloud provider or will I have to create small RAR archives of one large file to upload them?--Thanks!-James-"""]]
− doc/design/assistant/cloud/comment_2_08da8bc74a4845e354dca99184cffd70._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.8.126"- subject="re: cloud"- date="2012-06-11T04:48:08Z"- content="""-Yes, git-annex has to split files for certian providers. I already added support for this as part of my first pass at supporting box.com, see [[tips/using_box.com_as_a_special_remote]].-"""]]
doc/design/assistant/inotify.mdwn view
@@ -19,6 +19,19 @@    * Somehow track or detect if a file is open for write by any processes.     `lsof` could be used, although it would be a little slow.++    Here's one way to avoid the slowdown: When a file is being added,+    set it read-only, and hard-link it into a quarantine directory,+    remembering both filenames.+    Then use the batch change mode code to detect batch adds and bundle+    them together.+    Just before committing, lsof the quarantine directory. Any files in+    it that are still open for write can just have their write bit turned+    back on and be deleted from quarantine, to be handled when their writer+    closes. Files that pass quarantine get added as usual. This avoids+    repeated lsof calls slowing down adds, but does add a constant factor+    overhead (0.25 seconds lsof call) before any add gets committed.+   * Or, when possible, making a copy on write copy before adding the file     would avoid this.   * Or, as a last resort, make an expensive copy of the file and add that.
− doc/design/assistant/inotify/comment_1_3d3ff74447452d65c10ccc3dbfc323cd._commen 
@@ -1,7 +0,0 @@-[[!comment format=mdwn- username="http://ciffer.net/~svend/"- subject="comment 1"- date="2012-06-04T19:42:07Z"- content="""-I would find it useful if the watch command could 'git add' new files (instead of 'git annex add') for certain repositories.-"""]]
− doc/design/assistant/inotify/comment_2_a3c0fa6d97397c508b4b8aafdcee8f6f._commen 
@@ -1,7 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- subject="comment 2"- date="2012-06-04T19:46:03Z"- content="""-I think it's already on the list: \"configurable option to only annex files meeting certian size or filename criteria\" -- files not meeting those criteria would just be git added.-"""]]
− doc/design/assistant/progressbars/comment_1_3ea263b1f334e8e38e14f00a96202988._c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://abhidg.myopenid.com/"- ip="129.67.132.87"- subject="librsync"- date="2012-06-13T02:14:29Z"- content="""-There's librsync which might support reporting the progress through its API, but it seems to be in beta.-"""]]
− doc/forum/A_really_stupid_question/comment_1_40e02556de0b00b94f245a0196b5a89f._ 
@@ -1,31 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="Good question!"- date="2011-12-20T23:07:25Z"- content="""-You get a regular git merge conflict, which can be resolved in any of the regular ways, except that conflicting files are just symlinks.--Example:--<pre>-$ git pull-...-Auto-merging myfile-CONFLICT (add/add): Merge conflict in myfile-Automatic merge failed; fix conflicts and then commit the result.-$ git status-# On branch master-# Your branch and 'origin/master' have diverged,-# and have 1 and 1 different commit(s) each, respectively.-#-# Unmerged paths:-#   (use \"git add/rm <file>...\" as appropriate to mark resolution)-#-#	both added:         myfile-#-no changes added to commit (use \"git add\" and/or \"git commit -a\")-$ git add myfile-$ git commit -m \"took local version of the conflicting file\"-</pre>-"""]]
− doc/forum/Behaviour_of_fsck/comment_1_0e40f158b3f4ccdcaab1408d858b68b8._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-03-24T17:45:08Z"- content="""-I tend to agree that the default output of fsck is not quite right. I often use git annex fsck -q. A progress spinner display is a good idea.-"""]]
− doc/forum/Behaviour_of_fsck/comment_2_ead36a23c3e6efa1c41e4555f93e014e._comment 
@@ -1,19 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 2"- date="2011-03-26T10:57:41Z"- content="""-After some thought, perhaps the default fsck output should be at least machine readable and copy and pasteable i.e.--<pre>-$ git annex fsck-Files with errors--    file1-    file2--</pre>--so I can then copy the list of borked files and then just paste it into a for loop in my shell to recover the files. it's just an idea.-"""]]
− doc/forum/Behaviour_of_fsck/comment_3_97848f9a3db89c0427cfb671ba13300e._comment 
@@ -1,19 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 3"- date="2011-03-28T01:16:21Z"- content="""-Another nice thing would be a summary of _what_ is wrong. I.e.--    % git fsck-    [...]-    git-annex: 100 total failed-      50 checksum failed-      50 not enough copies exit--And the same/similar for all other failure modes.----- RichiH-"""]]
− doc/forum/Behaviour_of_fsck/comment_4_e4911dc6793f98fb81151daacbe49968._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 2"- date="2011-03-25T11:23:04Z"- content="""-FWIW, I wanted to suggest exactly the same thing.-"""]]
− doc/forum/Can_I_store_normal_files_in_the_git-annex_git_repository__63__.mdwn 
@@ -1,6 +0,0 @@-Is it possible to story ordinary files in the git repository, or is this going to confuse git-annex? In other words, can I safely run--    git add .gitattributes-    git commit -m 'remember attributes' .gitattributes--..., or do I have to use `git-annex add` all time?
− doc/forum/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comme 
@@ -1,7 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- subject="This is not an easy question to answer..."- date="2012-06-04T19:49:46Z"- content="""-Do you have a bug in git-annex that you need fixed, or are you just curious?-"""]]
− doc/forum/Error_while_adding_a_file___34__createSymbolicLink:_already_exists__3 
@@ -1,1 +0,0 @@-Moved to [[bugs|bugs/Error_while_adding_a_file___34__createSymbolicLink:_already_exists__34__]] --[[Joey]]
− doc/forum/Getting_started_with_Amazon_S3/comment_1_f50883133d5d4903cc95c0dcaa52 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.81.112"- subject="comment 1"- date="2012-05-29T19:09:50Z"- content="""-`git annex sync` only syncs git metadata, not file contents, and metadata is not stored on S3, so it does notthing (much).--`git annex move . --to s3` or `git annex copy . --to s3` is the right way to send the files to S3. I'm not sure why you say it's not working. I'd try it but Amazon is not letting me sign up for S3 again right now. Can you show what goes wrong with copy?-"""]]
− doc/forum/Getting_started_with_Amazon_S3/comment_2_e90aa3259d9a12cd67daa27d42d6 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnoUOqs_lbuWyZBqyU6unHgUduJwDDgiKY"- nickname="Matt"- subject="comment 2"- date="2012-05-30T00:40:45Z"- content="""-It's strange. I've done some testing on another machine, and this one, and the issue seems to be with adding only certain sub-directories of the git-annex directory. Would it cause an issue with git-annex if a sub-directory was a git repo?-"""]]
− doc/forum/Getting_started_with_Amazon_S3/comment_3_c3adce7c0f29e71ed9dd07103ede 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.81.112"- subject="comment 3"- date="2012-05-30T00:54:38Z"- content="""-If the subdirectory has a .git, then it's a separate git repo, and inside the directory, all git (and git-annex) commands in it will operate on that nested repo and ignore the outside one.-"""]]
− doc/forum/Git_Annex_Transfer_Protocols/comment_1_a870ec991078c95a6bb683d6962ab5 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.2.186"- subject="rsync over ssh"- date="2012-05-10T18:18:01Z"- content="""-Some other protocols such as S3 for special remotes.-"""]]
− doc/forum/Git_Annex_Transfer_Protocols/comment_2_71419376ef50a679ea8f0f9e16991c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"- nickname="Royal"- subject="Protocols to transfer file content"- date="2012-05-10T18:48:40Z"- content="""-Thanks, Is git annex is using same protocols as normal git to transfer content between normal git repositories?-"""]]
− doc/forum/Git_Annex_Transfer_Protocols/comment_3_fea43664a500111ca99f4043e0dadb 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.2.186"- subject="comment 3"- date="2012-05-10T18:51:56Z"- content="""-git-annex doesn't transfer git content between git repositories. You use git for that. Well, git-annex sync can run a few git commands for you to do it.-"""]]
− doc/forum/Git_Annex_Transfer_Protocols/comment_4_56fb2dab1d4030c9820be32b495afd 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"- nickname="Royal"- subject="Git annex content transfer protocols"- date="2012-05-10T19:13:48Z"- content="""-Sorry if I am not clear. Actually i meant to ask, if i have 2 git repositories which are not special remotes and I am transferring annexed file content between these repositories using git annex command (move or copy) then, which protocol it uses to transfer content? Is it uses git-send-pack git-recieve-pack or some other protocols. -"""]]
− doc/forum/Git_Annex_Transfer_Protocols/comment_5_a6ec9c5a4a3c0bac1df87f1df9be14 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.2.186"- subject="comment 5"- date="2012-05-10T19:17:22Z"- content="""-rsync over ssh is used to transfer file contents between repositories. (You can use the -d option to see the commands git-annex runs.)-"""]]
− doc/forum/Git_Annex_Transfer_Protocols/comment_6_1678452fb7114aeabcf0cc3d5f6c69 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawlYu7QmD7wrbHWkoxuriaA9XcijM-g5vrQ"- nickname="Royal"- subject="comment 6"- date="2012-05-10T19:21:08Z"- content="""-Ok. This helped me a lot. Thank you-"""]]
− doc/forum/How_to_expire_old_versions_of_files_that_have_been_edited__63__.mdwn 
@@ -1,7 +0,0 @@-My annex contains several large files that I have unlocked, edited, and committed again, i.e. the annex contains the version history of those files. However, I don't want the history -- keeping the latest version is good enough for me. Running `git annex unused` won't detect those old versions, though, because they aren't unused as old Git revisions still refer to them. So I wonder:--1. What is the best way to get rid of the old versions of files in the annex?--2. What is the best way to detect old versions of files in the annex?--I guess, I could run `git rebase -i` to squash commits to those files into one commit, thereby getting rid of the references to the old copies, but that approach feels awkward and error prone. Is anyone aware of a better way?
− doc/forum/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85d 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.2.245"- subject="comment 1"- date="2012-05-08T18:22:12Z"- content="""-git's code base makes lots of assumptions hardcoding the size of the hash, etc. (grep its source for magic numbers 40 and 42...) I'd like to see git get parameratised hashes. SHA1 insecurity may evenutally push it in that direction. However, when I asked the git developers about this at the Gittogether last year, there were several ideas floated that would avoid parameterisation, and a lot of good thoughts about problems parameterised hashes would cause.--Moving data into git proper would still leave the problems unique to large data of not being able to store it all on every clone. Which means a git-annex like thing is needed to track where the data resides and move it around.--(BTW, in markdown, you separate paragraphs with blank lines. Like in email.)-"""]]
− doc/forum/Moving_older_version__39__s_file_content_without_doing_checkout.mdwn 
@@ -1,4 +0,0 @@-Hi,-Is there any way I can move or copy file content of older version without doing checkout to that version, by passing commit hash as parameter in move command itself? --Thank you
− doc/forum/Podcast_syncing_use-case/comment_1_ace6f9d3a950348a3ac0ff592b62e786._ 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-11-27T17:56:31Z"- content="""-Right, --in goes by git-annex's [[location_tracking]] information; actually checking if a remote still has the files would make --in too expensive in many cases.--So you need to give `gpodder-on-usbdisk` current information. You can do that by going to `usb-ariaz` and doing a `git annex fsck`. That will find the deleted files and update the location information. Then, back on `gpodder-on-usbdisk`, `git pull usb-ariaz`, and then you can proceed with the commands you showed.-"""]]
− doc/forum/Podcast_syncing_use-case/comment_2_930a6620b4d516e69ed952f9da5371bb._ 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://cgray.myopenid.com/"- nickname="cgray"- subject="comment 2"- date="2011-11-27T22:10:44Z"- content="""-Thanks, that works perfectly!-"""]]
− doc/forum/Preserving_file_access_rights_in_directory_tree_below_objects__47__.m 
@@ -1,77 +0,0 @@-Hello,--I have the problem that, while git-annex preserves the file access rights (user, group, others) for the actual file, it does not make sure that others can access this file through the directory tree above said file:--    /tmp $ mkdir test-    /tmp $ chown claudius:media test-    /tmp $ chmod 750 test-    /tmp $ ls -dl test-    drwxr-x--- 2 claudius media 40 2012-01-23 19:27 test/-    /tmp $ cd test-    /tmp/test $ git init --shared=all-    Initialized empty shared Git repository in /tmp/test/.git/-    /tmp/test $ git annex init "test"-    init test ok-    /tmp/test $ echo 123 > abc-    /tmp/test $ chmod 640 abc-    /tmp/test $ chown claudius:media abc-    /tmp/test $ ls -l-    total 4-    -rw-r----- 1 claudius media 4 2012-01-23 19:27 abc-    /tmp/test $ git annex add .-    add abc (checksum...) ok-    (Recording state in git...)-    /tmp/test $ ls -l-    total 4-    lrwxrwxrwx 1 claudius claudius 176 2012-01-23 19:27 abc -> .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b-    /tmp/test $ ls -l .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b-    -r--r----- 1 claudius media 4 2012-01-23 19:27 .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b-    /tmp/test $ ls -lR .git/annex/objects/-    .git/annex/objects/:-    total 0-    drwx--S--- 3 claudius claudius 60 2012-01-23 19:28 8F/-    -    .git/annex/objects/8F:-    total 0-    drwx--S--- 3 claudius claudius 60 2012-01-23 19:28 pj/-    -    .git/annex/objects/8F/pj:-    total 0-    dr-x--S--- 2 claudius claudius 60 2012-01-23 19:28 SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b/-    -    .git/annex/objects/8F/pj/SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b:-    total 4-    -r--r----- 1 claudius media 4 2012-01-23 19:27 SHA256-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b-    /tmp/test $ stat .git/annex/objects/-      File: `.git/annex/objects/'-      Size: 60        	Blocks: 0          IO Block: 4096   directory-    Device: 11h/17d	Inode: 2365970     Links: 3-    Access: (2700/drwx--S---)  Uid: ( 1000/claudius)   Gid: ( 1000/claudius)-    Access: 2012-01-23 19:28:10.614948386 +0100-    Modify: 2012-01-23 19:28:10.614948386 +0100-    Change: 2012-01-23 19:28:10.614948386 +0100-     Birth: ---The use case is that I have a rather large collection of music I would like to manage with git-annex in various locations (all of it on my external hard drive, some on my notebook etc. This music is played by MPD, which can access the collection because it is in the "media" group. After changing to git-annex, however, this fails.--I tried to avoid this specific problem by declaring the git repository to be shared, which does appear to have some effect on the other files in .git:--    /tmp/test $ ls -l .git-    total 16-    drwx--S---  5 claudius claudius 160 2012-01-23 19:28 annex/-    drwxrwsr-x  2 claudius claudius  40 2012-01-23 19:27 branches/-    -rw-rw-r--  1 claudius claudius 218 2012-01-23 19:27 config-    -rw-rw-r--  1 claudius claudius  73 2012-01-23 19:27 description-    -rw-rw-r--  1 claudius claudius  23 2012-01-23 19:27 HEAD-    drwxrwsr-x  2 claudius claudius 220 2012-01-23 19:27 hooks/-    -rw-rw-r--  1 claudius claudius 104 2012-01-23 19:28 index-    drwxrwsr-x  2 claudius claudius  60 2012-01-23 19:27 info/-    drwxrwsr-x  3 claudius claudius  60 2012-01-23 19:27 logs/-    drwxrwsr-x 15 claudius claudius 300 2012-01-23 19:28 objects/-    drwxrwsr-x  4 claudius claudius  80 2012-01-23 19:27 refs/--I could obviously try to change the rights of annex/, annex/objects etc., but I would like to avoid having to adapt them each time a new folder is added somewhere below annex/objects/.--My knowledge of git and especially git-annex is not too good, so it might well be that I missed something obvious. Any hints? :)--(And thank you, of course, for taking the time to read all this)
− doc/forum/Recommended_number_of_repositories/comment_1_3ef256230756be8a9679b107 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="depends ..."- date="2011-11-04T19:59:24Z"- content="""-It makes sense to have separate repositories when you have well-defined uses for them. --I have a separate repository just for music and podcasts, which I can put various places where I have no need of the overhead of a tree of other files.--If you're using it for whatever arbitrary large files you accumulate, I find it's useful to have them in one repository. This way I can rearrange things as makes sense. It might make sense to have \"photos\" and \"isos\" as categories today, but next year you might prefer to move those under 2011/{photos,isos}. It would certainly make sense to have different repositories for home, work, etc.--How to split repositories up for a home directory is a general problem that the [vcs-home](http://vcs-home.branchable.com)-project has surely considered at one time or another.-"""]]
− doc/forum/Sharing_annex_with_local_clones/comment_1_2b60e13e5f7b8cee56cf2ddc6c4 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="don't do that"- date="2012-03-19T18:23:13Z"- content="""-Suppose you do that to repos A and B. Now, in A, you `git annex drop` a file that is only present in those repositories. A checks B to make sure it still has a copy of the file. It sees the (same) file there, so assumes it's safe to drop. The file is removed from A, also removing it from B, and losing data.--It is possible to configure A and B to mutually distrust one-another and avoid this problem, but there will be other problems too.--Instead, git-annex supports using `cp --reflink=auto`, which on filesystems supporting Copy On Write (eg, btrfs), avoids duplicating contents when A and B are on the same filesystem.-"""]]
− doc/forum/Sharing_annex_with_local_clones/comment_2_24ff2c1eb643077daa37c01644c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnhsaESlYphzLTzpJy5IxxGFxxctIhWYfo"- nickname="Bryon"- subject="comment 2"- date="2012-03-19T18:46:13Z"- content="""-Ah, OK. Is there a configuration step to set this up, or is this included magic in a new enough git-annex client?-"""]]
− doc/forum/Sharing_annex_with_local_clones/comment_3_5359b8eada24d27be83214ac0ae 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnhsaESlYphzLTzpJy5IxxGFxxctIhWYfo"- nickname="Bryon"- subject="comment 3"- date="2012-03-19T18:55:03Z"- content="""-Nevermind, found it. (git-annex 0.08)-"""]]
− doc/forum/Windows_support/comment_1_23fa9aa3b00940a1c1b3876c35eef019._comment 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-03-12T06:43:02Z"- content="""-[[todo/windows_support]] has everything I know about making a windows port. This badly needs someone who understand Windows to dive into it. The question of how to create a symbolic link (or the relevant Windows equivilant) from haskell on Windows-is a good starting point..-"""]]
− doc/forum/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943b 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-08-29T16:10:38Z"- content="""-You're right -- as long as nothing changes a file without letting the modification time update, editing WORM files is safe.-"""]]
− doc/forum/can_git-annex_replace_ddm__63__/comment_1_aa05008dfe800474ff76678a400 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-02-14T22:08:54Z"- content="""-Yes, there is value in layering something over git-annex to use a policy to choose what goes where.--I use [mr](http://kitenet.net/~joey/code/mr/) to update and manage all my repositories, and since mr can be made to run arbitrary commands when doing eg, an update, I use its config file as such a policy layer. For example, my podcasts are pulled into my sound repository in a subdirectory; boxes that consume podcasts run \"git pull; git annex get podcasts --exclude=\"*/out/*\"; git annex drop podcasts/*/out\". I move podcasts to \"out\" directories once done with them (I have yet to teach mpd to do that for me..), and the next time I run \"mr update\" to update everything, it pulls down new ones and removes old ones.--I don't see any obstacle to doing what you want. May be that you'd need better querying facilities in git-annex (so the policy layer can know what is available where), or finer control (--exclude is a good enough hammer for me, but maybe not for you).-"""]]
− doc/forum/can_git-annex_replace_ddm__63__/comment_2_008554306dd082d7f543baf2835 
@@ -1,19 +0,0 @@-[[!comment format=mdwn- username="http://dieter-be.myopenid.com/"- nickname="dieter"- subject="comment 2"- date="2011-02-16T21:32:04Z"- content="""-thanks Joey,--is it possible to run some git annex command that tells me, for a specific directory, which files are available in an other remote? (and which remote, and which filenames?)-I guess I could run that, do my own policy thingie, and run `git annex get` for the files I want.--For your podcast use case (and some of my use cases) don't you think git [annex] might actually be overkill?  For example your podcasts use case, what value does git annex give over a simple rsync/rm script?-such a script wouldn't even need a data store to store its state, unlike git. it seems simpler and cleaner to me.--for the mpd thing, check http://alip.github.com/mpdcron/ (bad project name, it's a plugin based \"event handler\")-you should be able to write a simple plugin for mpdcron that does what you want (or even interface with mpd yourself from perl/python/.. to use its idle mode to get events)--Dieter-"""]]
− doc/forum/can_git-annex_replace_ddm__63__/comment_3_4c69097fe2ee81359655e59a03a 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-03-16T03:01:17Z"- content="""-Whups, the comment above got stuck in moderation queue for 27 days. I will try to check that more frequently.--In the meantime, I've implemented \"git annex whereis\" -- enjoy!--I find keeping my podcasts in the annex useful because it allows me to download individual episodes or poscasts easily when low bandwidth is available (ie, dialup), or over sneakernet. And generally keeps everything organised.-"""]]
− doc/forum/confusion_with_remotes__44___map/comment_1_a38ded23b7f288292a843abcb1 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-10-17T19:01:21Z"- content="""-My guess is that psychosis has not pulled the git-annex branch since bacon was set up (or that bacon's git-annex branch has not been pushed to origin). git-annex status only shows remotes present in git-annex:uuid.log This may be a bug.--The duplicate links in the map I don't quite understand. I only see duplicate links in my maps when I have the same repository configured as two different git remotes (for example, because the same repository can be accessed two different ways). You don't seem to have that in your config.-"""]]
− doc/forum/confusion_with_remotes__44___map/comment_2_cd1c98b1276444e859a22c3dbd 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-10-17T19:02:50Z"- content="""-Actually, there is a hint that, while you ran the git annex map on psychosis, it decided to ssh to itself two times. That seems to be where the duplicate links came from, I guess you must have some git remotes you did not show.-"""]]
− doc/forum/confusion_with_remotes__44___map/comment_3_18531754089c991b6caefc57a5 
@@ -1,24 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"- nickname="Jim"- subject="comment 3"- date="2011-10-17T19:50:06Z"- content="""-No extra remotes (that I'm aware of); that output was only edited to change hostnames.--On all three hosts, \"git push origin\" and \"git pull origin\" say everything is up to date.--I'm using git-annex 3.20111011 on all hosts (although some were running 3.20110928 when I created the repositories).--Regarding the multiple links, I've put a copy of the dot file [here](http://jim.sh/~jim/tmp/map.dot).-It shows psychosis in three separate subgraphs, that are just getting rendered together as one,-if that helps clarify anything.--Wait, I just realized you said \"the git-annex branch\".  My origin only has \"master\".-Do you mean the one specifically named \"git-annex\"?  I thought that was something that-gets managed automatically, or is it something I need to manually check out and deal with?--Any other info I could provide?---"""]]
− doc/forum/confusion_with_remotes__44___map/comment_4_3b89b6d1518267fcbc050c9de0 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"- nickname="Jim"- subject="comment 4"- date="2011-10-17T20:36:51Z"- content="""-Ok, after pushing the \"git-annex\" branch to origin, then \"git annex status\" knows all repositories on all hosts, so that part makes sense now.  Thanks for the tip.  But the \"git annex map\" output hasn't changed.----"""]]
− doc/forum/confusion_with_remotes__44___map/comment_5_27801584325d259fa490f67273 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"- nickname="Jim"- subject="comment 5"- date="2011-10-18T04:59:13Z"- content="""-I think:--* The first extra edge is because bucket had \"ssh://psychosis.foo.com/vid/\", while-bacon had \"ssh://psychosis.foo.com/vid\" with no trailing slash.  That got lost in the hostname/path editing I did, sorry.-Maybe those should be considered matching?-* The second extra edge is because, when running \"git annex map\" from psychosis, it doesn't recognize the remote's-remote URL as pointing back to itself.--For the second case, after the \"spurious\" SSH, it could still recognize that the repositories are the same by the duplicated annex uuid, which currently shows up in `map.dot` twice.  I wonder what it would take to avoid the spurious SSH -- maybe some config that lists \"alternate\" URLs that should be considered the same as the current repository?  Or actually list URLs in uuid.log?  Fortunately, I think this only affects the map, so it's not a big problem.-"""]]
− doc/forum/confusion_with_remotes__44___map/comment_6_496b0d9b86869bbac3a1356d53 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 6"- date="2011-10-22T01:18:27Z"- content="""-Hmm, I don't see the spurious ssh edge in the dot file -- that is, I don't see any ssh:// uris in it?-"""]]
− doc/forum/confusion_with_remotes__44___map/comment_7_9a456f61f956a3d5e81e723d5a 
@@ -1,27 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnBJ6Dv1glxzzi4qIzGFNa6F-mfHIvv9Ck"- nickname="Jim"- subject="comment 7"- date="2011-10-22T05:25:47Z"- content="""-I think that's because the SSH was successful (I entered the password and let it connect), so it got the UUID and put that in the .dot instead.  The same UUID (for psychosis) then ended up in two different \"subgraph\" stanzas, and Graphviz just plotted them together as one node.--<p>Maybe this will clarify:--<p>On psychosis, run \"git annex map\" and press ^C at the ssh password prompt: [map-nossh.dot](http://jim.sh/~jim/tmp/map-nossh.dot)-![Map](http://jim.sh/~jim/tmp/map-nossh.png)--<p>On psychosis, run \"git annex map\" and type the correct password: [map-goodssh.dot](http://jim.sh/~jim/tmp/map-goodssh.dot)-![Map](http://jim.sh/~jim/tmp/map-goodssh.png)--As I see it:--* psychosis (\"localhost\") connects to each of its remotes-* some of them point back to ssh://psychosis-* psychosis doesn't know that ssh://psychosis is itself, so it tries to connect-* if successful:-  * psychosis gets put twice in the .dot as if it was two different hosts, one \"local\" and one \"ssh://psychosis\"-  * graphviz recognizes it as the same node because the UUID is the same, but graphviz still draws the extra connecting lines-* if unsuccessful:-  * ssh://psychosis is shown as an additional host that can't be reached-"""]]
− doc/forum/fsck_gives_false_positives/comment_1_b91070218b9d5fb687eeee1f244237ad 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-02-14T16:58:33Z"- content="""-Well, it should only move files to `.git/annex/bad/` if their filesize is wrong, or their checksum is wrong.--You can try moving a file out of `.git/annex/bad/` and re-run fsck and see if it fails it again. (And if it does, paste in a log!) --To do that -- -Suppose you have a file `.git/annex/bad/SHA256-s33--5dc45521382f1c7974d9dbfcff1246370404b952` and you know that file `foobar` was supposed to have that content (you can check that `foobar` is a symlink to that SHA value). Then reinject it:--`git annex reinject .git/annex/bad/SHA256-s33--5dc45521382f1c7974d9dbfcff1246370404b952 foobar`-"""]]
− doc/forum/fsck_gives_false_positives/comment_2_f51c53f3f6e6ee1ad463992657db5828 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="antymat"- ip="77.190.74.127"- subject="comment 2"- date="2012-02-14T22:48:37Z"- content="""-Thanks, joey, but I still do not know, why the file that has been (and *is*) OK according to separate sha1 and sha256 checks, has been marked 'bad' by `fsck` and moved to `.git/annex/bad`. What could be a reason for that? Could have `rsync` caused it? I know too little about internal workings of `git-annex` to answer this question.--But one thing I know for certain - the false positives should *not* happen, unless something *is* wrong with the file. Otherwise, if it is unreliable, if I have to check twice, it is useless. I might as well just keep checksums of all the files and do all checks by hand...-"""]]
− doc/forum/fsck_gives_false_positives/comment_3_692d6d4cd2f75a497e7d314041a768d2 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2012-02-14T22:57:29Z"- content="""-All that git annex fsck does is checksum the file and move it away if the checksum fails. --If bad data was somehow read from the disk that one time, what you describe could occur. I cannot think of any other way it could happen.-"""]]
− doc/forum/fsck_gives_false_positives/comment_4_7ceb395bf8a2e6a041ccd8de63b1b6eb 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="antymat"- ip="77.190.74.127"- subject="comment 4"- date="2012-02-15T07:13:12Z"- content="""-OK, thanks. I was just wondering - since there are links in git(-annex), and a hard links too, that maybe the issue has been caused by `rsync`.--I will keep my eye on that and run checks with my own checksum and `fsck` from time to time, and see what happens. I will post my results here, but the whole run (`fsck` or checksum) takes almost 2 days, so I will not do it too often... ;)-"""]]
− doc/forum/fsck_gives_false_positives/comment_5_86484a504c3bbcecd5876982b9c95688 
@@ -1,13 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 5"- date="2012-02-15T15:22:56Z"- content="""-The symlinks are in the git repository. So if the rsync damanged one, git would see the change. And nothing that happens to the symlinks can affect fsck.--git-annex does not use hard links at all.--fsck corrects mangled file permissions. It is possible to screw up the permissions so badly that it cannot see the files at all (ie, chmod 000 on a file under .git/annex/objects), but then fsck will complain and give up, not move the files to bad.-So I don't see how a botched rsync could result in fsck moving a file with correct content to bad.-"""]]
− doc/forum/git-annex_communication_channels/comment_1_198325d2e9337c90f026396de8 
@@ -1,17 +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-03-28T15:48:08Z"- content="""-No matter what you end up doing, I would appreciate a git-annex-announce@ list.--I really like the persistence of ikiwiki, but it's not ideal for quick communication. I would be fine with IRC and/or ML. The advantage of a ML over ikiwiki is that it doesn't seem to be as \"wasteful\" to mix normal chat with actual problem-solving.  But maybe that's merely my own perception.--Speaking of RSS: I thought I had added a wishlist item to ikiwiki about providing per-subsite RSS feeds. For example there is no (obvious) way to subscribe to changes in http://git-annex.branchable.com/forum/git-annex_communication_channels/ .--FWIW, I resorted to tagging my local clone of git-annex to keep track of what I've read, already.----- RichiH-"""]]
− doc/forum/git-annex_communication_channels/comment_2_c7aeefa6ef9a2e75d8667b479a 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 2"- date="2011-03-28T18:35:50Z"- content="""-I think the forums/website currently is sufficient, I do at times wish there was a mailing list or anonymous git push to the wiki as I find editing posts through the web browser is some times tedious (the lack of !fmt or alt-q bugs me at times ;) ). The main advantage of keeping stuff on the site/forum is that everything gets saved and passed on to anyone who checks out the git repo of the code base.-"""]]
− doc/forum/git-annex_communication_channels/comment_3_1ff08a3e0e63fa0e560cbc9602 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 3"- date="2011-03-28T20:47:23Z"- content="""-Push access to the non-code bits of git-annex' ikiwiki would be very welcome indeed. Given the choice, I would rather edit everything in Vim than in a browser. -- RichiH-"""]]
− doc/forum/git-annex_communication_channels/comment_4_1ba6ddf54843c17c7d19a9996f 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"- nickname="Yaroslav"- subject="comment 4"- date="2011-04-13T17:53:26Z"- content="""-.1 cents: Having IRC would be really nice for seeking quick help.   E.g. like I was trying to do now, google lead me to this page.-"""]]
− doc/forum/git-annex_communication_channels/comment_5_404b723a681eb93fee015cea80 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"- nickname="Christian"- subject="comment 5"- date="2011-04-14T11:24:59Z"- content="""-I would also like an git-annex channel. Would be #git-annex@OFTC ok?-"""]]
− doc/forum/git-annex_communication_channels/comment_6_0d87d0e26461494b1d7f8a701a 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 6"- date="2011-04-15T19:32:08Z"- content="""-We seem to be using #vcs-home @ OFTC for now. madduck is fine with it and joeyh pokes his head in there, as well. I just added a CIA bot to #vcs-home and this comment is a test if pushing works. -- RichiH-"""]]
− doc/forum/git-annex_communication_channels/comment_7_2c87c7a0648fe87c2bf6b4391f 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="anonymous git push"- date="2011-05-19T19:21:51Z"- content="""-@Jimmy mentioned anonymous git push -- that is now enabled for this wiki. Enjoy!--I may try to spend more time on #vcs-home -- or I can be summoned there from my other lurking places on irc, I guess.-"""]]
− doc/forum/git-subtree_support__63__/comment_1_4f333cb71ed1ff259bbfd86704806aa6. 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-01-03T17:00:53Z"- content="""-I have no experience using git-subtree, but as long as the home repository has the work one as a git remote, it will automatically merge work's git-annex branch with its own git-annex branch, and so will know what files are present at work, and will be able to get them.--Probably you won't want to make work have home as a remote, so work's git-annex will not know which files home has, nor will it be able to copy files to home (but home will be able to copy files to work).-"""]]
− doc/forum/git-subtree_support__63__/comment_2_73d2a015b1ac79ec99e071a8b1e29034. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://peter-simons.myopenid.com/"- ip="77.188.44.113"- subject="comment 2"- date="2012-01-03T18:11:37Z"- content="""-The point of git-subtree is that I can import another repository into sub-directory, i.e. I can have a directory called \"work\" that contains all files from the annex I have at work. If I make the other annex a remote and merge its contents, then all contents is going to be merged at the top-level, which is somewhat undesirable in my particular case.-"""]]
− doc/forum/git-subtree_support__63__/comment_3_c533400e22c306c033fcd56e64761b0b. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2012-01-03T18:42:08Z"- content="""-You can make it a remote without merging its contents. Git will not merge its contents by default unless it's named \"origin\". git-annex will be prefectly happy with that.-"""]]
− doc/forum/git-subtree_support__63__/comment_4_75b0e072e668aa46ff0a8d62a6620306. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://peter-simons.myopenid.com/"- ip="77.188.44.113"- subject="comment 4"- date="2012-01-03T19:17:36Z"- content="""-Okay, I see, but is `git annex get --auto .` going to import all those files from the work remote into my home if the `master` branch of that remote isn't merged?-"""]]
− doc/forum/git-subtree_support__63__/comment_5_f5ec9649d9f1dc122e715de5533bc674. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 5"- date="2012-01-03T19:31:45Z"- content="""-Yes; git-annex uses the git-annex branch independently of the branch you have checked out. You may find [[internals]] interesting reading, but the short answer is it will work.-"""]]
− doc/forum/git-subtree_support__63__/comment_6_85df530f7b6d76b74ac8017c6034f95e. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://peter-simons.myopenid.com/"- ip="77.188.44.113"- subject="comment 6"- date="2012-01-03T19:47:11Z"- content="""-Very cool! Thank you for the explanation.-"""]]
− doc/forum/git_pull_remote_git-annex/comment_1_9c245db3518d8b889ecdf5115ad9e053. 
@@ -1,36 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-12-06T16:43:29Z"- content="""-You're taking a very long and strange way to a place that you can reach as follows:--<pre>-git pull remote-git annex get .-</pre>--Which is just as shown in [[walkthrough/getting_file_content]]. --In particular, \"git pull remote\" first fetches all branches from the remote, including the git-annex branch.-When you say \"git pull remote master\", you're preventing it from fetching the git-annex branch. -If for some reason you want the slightly longer way around, it is:--<pre>-git pull remote master-git fetch remote git-annex-git annex get .-</pre>--Or, eqivilantly but with less network connections:--<pre>-git fetch remote-git merge remote/master-git annex get .-</pre>--BTW, notice that this is all bog-standard git branch pulling stuff, not specific to git-annex in the least.-Consult your extensive and friendly git documentation for details. :)-"""]]
− doc/forum/git_pull_remote_git-annex/comment_2_0f7f4a311b0ec1d89613e80847e69b42. 
@@ -1,14 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"- nickname="Matt"- subject="comment 2"- date="2011-12-06T23:23:29Z"- content="""-Doh! Total brain melt on my part. Thanks for the additional info.  Not taking my time and reading things properly - kept assuming that the full remote pull failed due to the warning:--    You asked to pull from the remote 'rss', but did not specify-    a branch. Because this is not the default configured remote-    for your current branch, you must specify a branch on the command line.--Rookie mistake indeed.-"""]]
− doc/forum/git_pull_remote_git-annex/comment_3_1aa89725b5196e40a16edeeb5ccfa371. 
@@ -1,14 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU"- nickname="Matt"- subject="comment 3"- date="2011-12-21T16:06:25Z"- content="""-hmmmm - I'm still not sure I get this.--If I'm using a whole bunch of distributed annexs with no central repo, then I can not do a `git pull remote` without either specifying the branch to use or changing default tracked remote via `git branch --set-upstream`.  The former like you note doesn't pull the git-annex branch down the latter only works one-at-a-time.--The docs read to me as though I ought to be able to do a `git pull remote ; git annex get .` using anyone of my distributed annexs.--Am I doing something wrong?  Or is the above correct?-"""]]
− doc/forum/git_pull_remote_git-annex/comment_4_646f2077edcabc000a7d9cb75a93cf55. 
@@ -1,37 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="I think Matt is right."- date="2011-12-23T14:04:44Z"- content="""-I got bitten by this too.  It seems that the user is expected to fetch-remote git-annex branches themselves, but this is not documented-anywhere.--The man page says of \"git annex merge\":--    Automatically merges any changes from remotes into the git-annex-    branch.--I am not a git newbie, but even so I had incorrectly assumed that git-annex merge would take care of pulling the git-annex branch from the-remote prior to merging, thereby ensuring all versions of the-git-annex branch would be merged, and that the location tracking data-would be synced across all peer repositories.--My master branches do not track any specific upstream branch, because-I am operating in a decentralized fashion.  Therefore the error-message caused by `git pull $remote` succeeded in encouraging me to-instead use `git pull $remote master`, and this excludes the git-annex-branch from the fetch.  Even worse, a git newbie might realise this-and be tempted to do `git pull $remote git-annex`.--Therefore I think it needs to be explicitly documented that--    git fetch $remote-    git merge $remote/master--is required when the local branch doesn't track an upstream branch.-Or maybe a `--fetch` option could be added to `git annex merge` to-perform the fetch from all remotes before running the merge(s).-"""]]
− doc/forum/git_pull_remote_git-annex/comment_5_4f2a05ef6551806dd0ec65372f183ca4. 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 5"- date="2011-12-23T16:50:26Z"- content="""-My goal for `git-annex merge` is that users should not need to know about it, so it should not be doing expensive pulls.--I hope that `git annex sync` will grow some useful features to support fully distributed git usage, as being discussed in [[pure_git-annex_only_workflow]]. I still use centralized git to avoid these problems myself.-"""]]
− doc/forum/git_pull_remote_git-annex/comment_6_3925d1aa56bce9380f712e238d63080f. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="comment 6"- date="2011-12-23T17:14:03Z"- content="""-Extending `git annex sync` would be nice, although auto-commit does not suit every use case, so it would be better not to couple one to the other.-"""]]
− doc/forum/git_pull_remote_git-annex/comment_7_24c45ee981b18bc78325c768242e635d. 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="comment 7"- date="2011-12-23T17:24:58Z"- content="""-P.S. I see you already [fixed the docs](http://source.git-annex.branchable.com/?p=source.git;a=commitdiff;h=a0227e81f9c82afc12ac1bd1cecd63cc0894d751) - thanks! :)-"""]]
− doc/forum/git_pull_remote_git-annex/comment_8_7e76ee9b6520cbffaf484c9299a63ad3. 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="git tweak-fetch"- date="2011-12-26T18:50:35Z"- content="""-The git tweak-fetch hook that I have been developing, and hope will be accepted into git soon, provides some abilities that could be used to make \"git pull remote\" always merge remote/master. Normall, git can only be configured to do that merge automatically for one remote (ie, origin). But the tweak-fetch hook can flag arbitrary branches as needing merge. --So, it could always flag tracking branches of the currently checked out branch for merge. This would be enabled by some setting, probably, since it's not necessarily the case that everyone wants to auto-merge when they pull like this. (Which is why git doesn't do it by default after all.)--(The tweak-fetch hook will also entirely eliminate the need to run git annex merge manually, since it can always take care of merging the git-annex branch.)-"""]]
− doc/forum/git_tag_missing_for_3.20111011/comment_1_7a53bf273f3078ab3351369ef2b5 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="fixed that"- date="2011-10-13T15:36:59Z"- content="""-:)-"""]]
− doc/forum/hashing_objects_directories/comment_1_c55c56076be4f54251b0b7f79f28a60 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-03-14T16:12:49Z"- content="""-My experience is that modern filesystems are not going to have many issues with tens to hundreds of thousands of items in the directory. However, if a transition does happen for FAT support I will consider adding hashing. Although getting a good balanced hash in general without, say, checksumming the filename and taking part of the checksum, is difficult. --I prefer to keep all the metadata in the filename, as this eases recovery if the files end up in lost+found. So while \"SHA/\" is a nice workaround for the FAT colon problem, I'll be doing something else. (What I'm not sure yet.)--There is no point in creating unused hash directories on initialization. If anything, with a bad filesystem that just guarantees worst performance from the beginning..-"""]]
− doc/forum/hashing_objects_directories/comment_2_504c96959c779176f991f4125ea2200 
@@ -1,14 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 2"- date="2011-03-15T13:52:16Z"- content="""-Can't you just use an underscore instead of a colon?--Would it be feasible to split directories dynamically? I.e. start with SHA1_123456789abcdef0123456789abcdef012345678/SHA1_123456789abcdef0123456789abcdef012345678 and, at a certain cut-off point, switch to shorter directory names? This could even be done per subdirectory and based purely on a locally-configured number. Different annexes on different file systems or with different file subsets might even have different thresholds. This would ensure scale while not forcing you to segment from the start. Also, while segmenting with longer directory names means a flatter tree, segments longer than four characters might not make too much sense. Segmenting too often could lead to some directories becoming too populated, bringing us back to the dynamic segmentation.--All of the above would make merging annexes by hand a _lot_ harder, but I don't know if this is a valid use case. And if all else fails, one could merge everything with the unsegemented directory names and start again from there.---- RichiH-"""]]
− doc/forum/hashing_objects_directories/comment_3_9134bde0a13aac0b6a4e5ebabd7f22e 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-03-16T03:13:39Z"- content="""-It is unfortunatly not possible to do system-dependant hashing, so long as git-annex stores symlinks to the content in git.--It might be possible to start without hashing, and add hashing for new files after a cutoff point. It would add complexity.--I'm currently looking at a 2 character hash directory segment, based on an md5sum of the key, which splits it into 1024 buckets. git uses just 256 buckets for its object directory, but then its objects tend to get packed away. I sorta hope that one level is enough, but guess I could go to 2 levels (objects/ab/cd/key), which would provide 1048576 buckets, probably plenty, as if you are storing more than a million files, you are probably using a modern enough system to have a filesystem that doesn't need hashing.-"""]]
− doc/forum/hashing_objects_directories/comment_4_0de9170e429cbfea66f5afa8980d45a 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-03-16T04:06:19Z"- content="""-The .git-annex/ directory is what really needs hashing.--Consider that when git looks for changes in there, it has to scan every file in the directory. With hashing, it should be able to more quickly identify just the subdirectories that contained changed files, by the directory mtimes.--And the real kicker is that when committing there, git has to create a tree object containing every single file, even if only 1 file changed. That will be a lot of extra work; with hashed subdirs it will instead create just 2 or 3 small tree objects leading down to the changed file. (Probably these trees both pack down to similar size pack files, not sure.)-"""]]
− doc/forum/hashing_objects_directories/comment_5_ef6cfd49d24c180c2d0a062e5bd3a0b 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 5"- date="2011-03-16T15:47:17Z"- content="""-If you can't segment the names retroactively, it's better to start with segmenting, imo.--As subdirectories are cheap, going with ab/cd/rest or even ab/cd/ef/rest by default wouldn't hurt.--Your point about git not needing to create as many tree objects is a kicker indeed. If I were you, I would default to segmentation.-"""]]
− doc/forum/incompatible_versions__63__/comment_1_629f28258746d413e452cbd42a1a43f 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-06-08T00:40:54Z"- content="""-They are not. See [[upgrades]]-"""]]
− doc/forum/location_tracking_cleanup/comment_1_7d6319e8c94dfe998af9cfcbf170efb2. 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-09-30T06:55:34Z"- content="""-Specifying the UUID was supposed to work, I think I broke it a while ago. Fixed now in git.--I'm not sure why you need to look up the UUID of the current repository. You can always refer to the current repository as \".\". Anyway, the UUID of the current repository is in `.git/config`, or use `git config annex.uuid`.-"""]]
− doc/forum/location_tracking_cleanup/comment_2_e7395cb6e01f42da72adf71ea3ebcde4. 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawncBlzaDI248OZGjKQMXrLVQIx4XrZrzFo"- nickname="Perttu"- subject="comment 2"- date="2011-09-30T11:55:35Z"- content="""-Thanks for the quick reply :)--I wanted to look up the UUID of the current repo so that I can find out which repo is alive from the collection of repos with the same name.-I could have looked for it in .git/config though, since it's pretty obvious. I just looked into the git-annex branch and didn't find it there.-Thanks for the tip about using \".\". By the way, could there be some kind of warning about using non-unique names for repos? That would make this-scenario less likely. Or maybe that is a bad idea given the decentralized nature of git.--By the way, do the trust settings propagate to other repos? If I mark some UUID as untrusted on one computer does it become globally untrusted?-"""]]
− doc/forum/location_tracking_cleanup/comment_3_c15428cec90e969284a5e690fb4b2fde. 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-09-30T16:47:27Z"- content="""-`git annex status` now includes a list of all known repositories.--Yes, trust setting propigate on git push/pull like any other git-annex information.-"""]]
− doc/forum/new_microfeatures/comment_1_058bd517c6fffaf3446b1f5d5be63623._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 1"- date="2011-06-01T17:36:50Z"- content="""-I've been longing for an automated way of removing references to a remote assuming I know the exact uuid that I want to remove. i.e. I have lost a portable HDD due to a destructive process, I now want to delete all references to copies of data that was on that disk. Unless this feature exists, I would love to see it implemented.-"""]]
− doc/forum/new_microfeatures/comment_2_41ad904c68e89c85e1fc49c9e9106969._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-06-01T20:24:33Z"- content="""-@jimmy [[walkthrough/what_to_do_when_you_lose_a_repository]].. I have not seen a convincing argument that removing the location tracking data entirely serves any purpose-"""]]
− doc/forum/new_microfeatures/comment_3_a1a9347b5bc517f2a89a8b292c3f8517._comment 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"- nickname="Rafaël"- subject="git annex unlock --readonly"- date="2011-06-02T11:34:42Z"- content="""-This was already asked [here](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606577), but I have a use case where I need to unlock with the files being hardlinked instead of copied (my fs does not support CoW), even though 'git annex lock' is now much faster ;-) . The idea is that 1) I want the external world see my repo \"as if\" it wasn't annexed (because of its own limitation to deal with soft links), and 2) I know what I do, and am sure that files won't be written to but only read.--My case is: the repo contains a snapshot A1 of a certain remote directory. Later I want to rsync this dir into a new snapshot A2. Of course, I want to transfer only new or changed files, with the --copy-dest=A1 (or --compare-dest) rsync's options. Unfortunately, rsync won't recognize soft-links from git-annex, and will re-transfer everything.---Maybe I'm overusing git-annex ;-) but still, I find it is a legitimate use case, and even though there are workarounds (I don't even remember what I had to do), it would be much more straightforward to have 'git annex unlock --readonly' (or '--readonly-unsafe'?), ... or have rsync take soft-links into account, but I did not see the author ask for microfeatures ideas :) (it was discussed, and only some convoluted workarounds were proposed). Thanks.---"""]]
− doc/forum/new_microfeatures/comment_4_5a6786dc52382fff5cc42fdb05770196._comment 
@@ -1,18 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"- nickname="Rafaël"- subject="git annex unused"- date="2011-06-02T11:55:58Z"- content="""-Before dropping unsused items, sometimes I want to check the content of the files manually.-But currently, from e.g. a sha1 key, I don't know how to find the corresponding file, except with-'find .git/annex/objects -type f -name 'SHA1-s1678--70....', wich is too slow (I'm in the case where \"git log --stat -S'KEY'\"-won't work, either because it is too slow or it was never commited). By the way,-is it documented somewhere how to determine the 2 (nested) sub-directories in which a given-(by name) object is located?--So I would like 'git-annex unused' be able to give me the list of *paths* to the unused items.-Also, I would really appreciate a command like 'git annex unused --log NUMBER [NUMBER2...]' which would do for me the suggested command-\"git log --stat -S'KEY'\", where NUMBER is from the 'git annex unused' output.-Thanks.-"""]]
− doc/forum/new_microfeatures/comment_5_3c627d275586ff499d928a8f8136babf._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"- nickname="Rafaël"- subject="git annex unused"- date="2011-06-02T19:51:49Z"- content="""-ps: concerning the command 'find .git/annex/objects -type f -name 'SHA1-s1678--70....' from my previous comment, it is \"significantly\" faster to search for the containing directory which have the same name: 'find .git/annex/objects -maxdepth 2 -mindepth 2 -type d -name 'SHA1-s1678--70....'. I am just curious: what is the need to have each file object in its own directory, itself nested under two more sub-directories?-"""]]
− doc/forum/new_microfeatures/comment_6_31ea08c008500560c0b96c6601bc6362._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"- nickname="Rafaël"- subject="git annex fetch"- date="2011-07-03T14:39:41Z"- content="""-I'm not sure it is worth adding a command for such a small feature, but I would certainly use it: having something like \"git annex fetch remote\" do \"git fetch remote && git annex copy --from=remote\", and \"git annex push remote\" do \"git push remote && git annex copy --to=remote\". And maybe the same for a pull operation?-"""]]
− doc/forum/new_microfeatures/comment_7_94045b9078b1fff877933b012d1b49e2._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawnpdM9F8VbtQ_H5PaPMpGSxPe_d5L1eJ6w"- nickname="Rafaël"- subject="git annex fetch"- date="2011-07-03T17:57:00Z"- content="""-My last comment is a bit confused. The \"git fetch\" command allows to get all the information from a remote, and it is then possible to merge while being offline (without access to the remote). I would like a \"git annex fetch remote\" command to be able to get all annexed files from remote, so that if I later merge with remote, all annexed files are already here. And \"git annex fetch\" could (optionally) call \"git fetch\" before getting the files.--It seems also that in my last post, I should have written \"git annex get --from=remote\" instead of \"git annex copy --from=remote\", because \"annex copy --from\" copies all files, even if the local repo already have them (is this the case? if yes, when is it useful?)-"""]]
− doc/forum/performance_improvement:_git_on_ssd__44___annex_on_spindle_disk.mdwn 
@@ -1,12 +0,0 @@-This works with bind-mount, I might try with softlinks as well.--Going through git's data on push/pull can take ages on a spindle disk even-if the repo is rather small in size. This is especially true if you are-used to ssd speeds, but ssd storage is expensive. Storing the annex objects-on a cheap spindle disk and everything else on a ssd makes things a _lot_-faster.--> Update: git-annex supports `.git/annex/` being moved to a different disk-> than the rest of the repisitory, but does *not* support individual -> subdirectories, like `.git/annex/objects/` being on a different disk-> than the main `.git/annex/` directory. --[[Joey]]
− doc/forum/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._ 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-03-14T16:23:25Z"- content="""-I've made git-annex-shell run the git `hooks/annex-content` after content is received or dropped. --Note that the clients need to be running at least git-annex version 3.20120227 , which runs git-annex-shell commit, which runs the hook.--"""]]
− doc/forum/pure_git-annex_only_workflow/comment_10_683768c9826b0bf0f267e8734b9eb 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="Finally some code"- date="2011-12-29T19:58:31Z"- content="""-The repository at http://git.nomeata.de/?p=git-annex.git;a=summary contains changes to Commands/Sync.hs (and to the manpage) that implements this behavior. The functionality should be fine; the progress output is not very nice yet, but I’m not sure if I really understood the various Command types. It also should be more easily discoverable how to activate the behavior (by running \"git branch synced/master\") by providing a helpful message, at least unless git annex init creates the branch by default.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_11_6b541ed834ef45606f3b98779a25a 
@@ -1,30 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 11"- date="2011-12-30T21:49:06Z"- content="""-OMG, my first sizable haskell patch!--So trying this out..--In each repo I want to sync, I first `git branch synced/master`--Then in each repo, I found I had to pull from each of its remotes, to get the tracking branches that `defaultSyncRemotes` looks for to know those remotes are syncable. This was the surprising thing for me, I had expected sync to somehow work out which remotes were syncable without my explicit pull. And it was not very obvious that sync was not doing its thing before I did that, since it still does a lot of \"stuff\".--Once set up properly, `git annex sync` fetches from each remote, merges, and then pushes to each remote that has a synced branch. Changes propigate around even when some links are one-directional. Cool!--So it works fine, but I think more needs to be done to make setting up syncing easier. Ideally, all a user would need to do is run \"git annex sync\" and it syncs from all remotes, without needing to manually set up the synced/master branch.--While this would lose the ability to control which remotes are synced, I think that being able to `git annex sync origin` and only sync from/to origin is sufficient, for the centralized use case.-------Code review:--Why did you make `branch` strict?--There is a bit of a bug in your use of Command.Merge.start. The git-annex branch merge code only runs once per git-annex run, and often this comes before sync fetches from the remotes, leading to a push conflict. I've fixed this in my \"sync\" branch, along with a few other minor things.--`mergeRemote` merges from `refs/remotes/foo/synced/master`. But that will only be up-to-date if `git annex sync` has recently been run there. Is there any reason it couldn't merge from `refs/remotes/foo/master`?-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_12_ca8ca35d6cd4a9f94568536736c12 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 12"- date="2011-12-30T23:45:57Z"- content="""-I have made a new `autosync` branch, where all that the user needs to do is run `git annex sync` and it automatically sets up the synced/master branch. I find this very easy to use, what do you think?--Note that `autosync` is also pretty smart about not running commands like \"git merge\" and \"git push\" when they would not do anything. So you may find `git annex sync` not showing all the steps you'd expect. The only step a sync always performs now is pulling from the remotes.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_13_00c82d320c7b4bb51078beba17e14 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 13"- date="2011-12-31T18:34:31Z"- content="""-I have merged my autosync branch, the improved sync command will be in this year's last git-annex release!-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_14_b63568b327215ef8f646a39d760fd 
@@ -1,32 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 14"- date="2012-01-02T14:02:04Z"- content="""-Sorry for not replying earlier, but my non-mailinglist-communications-workflows are suboptimal :-)--> Then in each repo, I found I had to pull from each of its remotes, to get the tracking branches that defaultSyncRemotes looks for to know those remotes are syncable.  This was the surprising thing for me, I had expected sync to somehow work out which remotes were syncable without my explicit pull. And it was not very obvious that sync was not doing its thing before I did that, since it still does a lot of \"stuff\".--Right. But \"git fetch\" ought to be enough.--Personally, I’d just pull and push everywhere, but you pointed out that it ought to be manageable. The existence of the synced/master branch is the flag that indicates this, so you need to propagate this once. Note that if the branch were already created by \"git annex init\", then this would not be a problem.--It is not required to use \"git fetch\" once, you can also call \"git annex sync <remote>\" once with the remote explicitly mentioned; this would involve a fetch.--> While this would lose the ability to control which remotes are synced, I think that being able to git annex sync origin and only sync from/to origin is sufficient, for the centralized use case.--I’d leave this decision to you. But I see that you took the decision already, as your code now creates the synced/master branch when it does not exist (e290f4a8).--> Why did you make branch strict?--Because it did not work otherwise :-). It uses pipeRead, which is lazy, and for some reason git and/or your utility functions did not like that the output of the command was not consumed before the next git command was called. I did not investigate further. For better code, I’d suggest to add a function like pipeRead that completely reads the git output before returning, thus avoiding any issues with lazyIO.--> mergeRemote merges from refs/remotes/foo/synced/master. But that will only be up-to-date if git annex sync has recently been run there. Is there any reason it couldn't merge from refs/remotes/foo/master?--Hmm, good question. It is probably save to merge from both, and push only to synced/master. But which one first? synced/master can be ahead if the repo was synced to from somewhere else, master can be ahead if there are local changes. Maybe git merge should be called on all remote heads simultaniously, thus generating only one commit for the merge. I don’t know how well that works in practice.--Thanks for including my code,-Joachim--"""]]
− doc/forum/pure_git-annex_only_workflow/comment_15_cb7c856d8141b2de3cc95874753f1 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 15"- date="2012-01-02T16:01:49Z"- content="""-With a lazy branch, I get \"git-annex: no branch is checked out\". Weird.. my best guess is that it's because this is running at the seek stage, which is unusual, and the value is not used until a later stage and so perhaps the git command gets reaped by some cleanup code before its output is read.--(pipeRead is lazy because often it's used to read large quantities of data from git that are processed progressively.)--I did make it merge both branches, separately. It would be possible to do one single merge, but it's probably harder for the user to recover if there are conflicts in an octopus merge. The order of the merges does not seem to me to matter much, barring conflicts it will work either way. Dealing with conflicts during sync is probably a weakness of all this; after the first conflict the rest of the sync will continue failing.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_1_a32f7efd18d174845099a4ed59e6fe 
@@ -1,32 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-12-09T22:56:11Z"- content="""-First, you need a bare git repository that you can push to, and pull from. This simplifies most git workflow.--Secondly, I use [mr](http://kitenet.net/~joey/code/mr/), with this in `.mrconfig`:--<pre>-[DEFAULT]-lib =-        annexupdate() {-                git commit -a -m update || true-                git pull \"$@\"-                git annex merge-                git push || true-        }--[lib/sound]-update = annexupdate-[lib/big]-update = annexupdate-</pre>--Which makes \"mr update\" in repositories where I rarely care about git details take care of syncing my changes.--I also make \"mr update\" do a \"git annex get\" of some files in some repositories that I want to always populate. git-annex and mr go well together. :)--Perhaps my annexupdate above should be available as \"git annex sync\"?-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_2_66dc9b65523a9912411db03c039ba8 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 2"- date="2011-12-10T16:28:29Z"- content="""-Thanks for the tips so far. I guess a bare-only repo helps, but as well is something that I don’t _need_ (for my use case), any only have to do because git works like this.--Also, if I have a mobile device that I want to push to, then I’d have to have two repositories on the device, as I might not be able to reach my main bare repository when traveling, but I cannot push to the „real“ repo on the mobile device from my computer. I guess I am spoiled by darcs, which will happily push to a checked out -remote repository, updating the checkout if possible without conflict.--If I introduce a central bare repository to push to and from; I’d still have to have the other non-bare repos as remotes, so that git-annex will know about them and their files, right?--I’d appreciate a \"git annex sync\" that does what you described (commit all, pull, merge, push). Especially if it comes in a \"git annex sync --all\" variant that syncs all reachable repositories.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_3_9b7d89da52f7ebb7801f9ec8545c3a 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-12-10T19:43:04Z"- content="""-Git can actually push into a non-bare repository, so long as the branch you change there is not a checked out one. Pushing into `remotes/$foo/master` and `remotes/$foo/git-annex` would work, however determining the value that the repository expects for `$foo` is something git cannot do on its own. And of course you'd still have to `git merge remotes/$foo/master` to get the changes. --Yes, you still keep the non-bare repos as remotes when adding a bare repository, so git-annex knows how to get to them.--I've made `git annex sync` run the simple script above. Perhaps it can later be improved to sync all repositories.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_4_dc8a3f75533906ad3756fcc47f7e96 
@@ -1,20 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 4"- date="2011-12-13T18:16:08Z"- content="""-I thought about this some more, and I think I have a pretty decent solution that avoids a central bare repository. Instead of pushing to master (which git does not like) or trying to guess the remote branch name on the other side, there is a well-known branch name, say git-annex-master. Then a sync command would do something like this (untested):--    git commit -a -m 'git annex sync' # ideally with a description derived from the diff-    git merge git-annex-master-    git pull someremote git-annex-master # for all reachable remotes. Or better to use fetch and then merge everything in one command?-    git branch -f git-annex-master # (or checkout git-annex-master, merge master, checkout master, but since we merged before this should have the same effect-    git annex merge-    git push someremote git-annex-master # for all reachable remotes--The nice things are: One can push to any remote repository, and thus avoid the issue of pushing to a portable device; the merging happens on the master branch, so if it fails to merge automatically, regular git foo can resolve it, and all changes eventually reach every repository.--What do you think?-    -"""]]
− doc/forum/pure_git-annex_only_workflow/comment_5_afe5035a6b35ed2c7e193fb69cc182 
@@ -1,24 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 5"- date="2011-12-13T18:47:18Z"- content="""-After some experimentation, this seems to work better:--    	git commit -a -m 'git annex sync'-	git merge git-annex-master-	for remote in $(git remote)-	do-		git fetch $remote-		git merge $remote git-annex-master-	done-	git branch -f git-annex-master-	git annex merge-	for remote in $(git remote)-	do-		git push $remote git-annex git-annex-master-	done--Maybe this approach can be enhance to skip stuff gracefully if there is no git-annex-master branch and then be added to what \"git annex sync\" does, this way those who want to use the feature can do so by running \"git branch git-annex-master\" once. Or, if you like this and want to make it default, just make git-annex-init create the git-annex-master branch :-)-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_6_3660d45c5656f68924acbd23790024 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 6"- date="2011-12-13T20:53:23Z"- content="""-It would be clearer to call \"git-annex-master\" \"synced/master\" (or really \"synced/$current_branch\"). That does highlight that this method of syncing is not particularly specific to git-annex.--I think this would be annoying to those who do use a central bare repository, because of the unnecessary pushing and pulling to other repos, which could be expensive to do, especially if you have a lot of interconnected repos. So having a way to enable/disable it seems best.--Maybe you should work up a patch to Command/Sync.hs, since I know you know haskell :)-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_7_33db51096f568c65b22b4be0b5538c 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 7"- date="2011-12-18T12:08:51Z"- content="""-I agree on the naming suggestions, and that it does not suit everybody. Maybe I’ll think some more about it. The point is: I’m trying to make live easy for those who do not want to manually create some complicated setup, so if it needs configuration, it is already off that track. But turning the current behavior into something people have to configure is also not well received by the users.--Given that \"git annex sync\" is a new command, maybe it is fine to have this as a default behavior, and offer an easy way out. The easy way out could be one of two flags that can be set for a repo (or a remote):--* \"central\", which makes git annex sync only push and pull to and that repo (unless a different remote is given on the command line)-* \"unsynced\", which makes git annex sync skip the repo.--Maybe central is enough.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_8_6e5b42fdb7801daadc0b3046cbc3d5 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 8"- date="2011-12-19T18:29:01Z"- content="""-I don't mind changing the behavior of git-annex sync, certianly..--Looking thru git's documentation, I found some existing configuration that could be reused following your idea.-There is a remote.name.skipDefaultUpdate and a remote.name.skipFetchAll. Though both have to do with fetches, not pushes.-Another approach might be to use git's remote group stuff.-"""]]
− doc/forum/pure_git-annex_only_workflow/comment_9_ace319652f9c7546883b5152ddc825 
@@ -1,14 +0,0 @@-[[!comment format=mdwn- username="http://www.joachim-breitner.de/"- nickname="nomeata"- subject="comment 9"- date="2011-12-19T22:56:26Z"- content="""-Another option that would please the naive user without hindering the more advanced user: \"git annex init\", by default, creates a synced/master branch. \"git annex sync\" will pull from every <remote>/sync/master branch it finds, and also push to any <remote>/sync/master branch it finds, but will not create any. So by default (at least for new users), this provides simple one-step syncing.--Advanced users can disable this per-repo by just deleting the synced/master branch. Presumably the logic will be: Every repo that should not be pushed to, because it has access to some central repo, should not have a synced/master branch. Every other repo, including the (or one of the few) central repos, will have the branch.--This is not the most expressive solution, as it does not allow configuring syncing between arbitrary pairs of repos, but it feels like a good compromise between that and simplicity and transparency.--I think it's about time that I provide less talk and more code. I’ll see when I find the time :-)-"""]]
− doc/forum/relying_on_git_for_numcopies/comment_1_8ad3cccd7f66f6423341d71241ba89 
@@ -1,36 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-02-22T18:44:28Z"- content="""-I see the following problems with this scheme:--- Disallows removal of files when disconnected. It's currently safe to force that, as long as-  git-annex tells you enough other repos are belived to have the file. Just as long as you-  only force on one machine (say your laptop). With your scheme, if you drop a file while -  disconnected, any other host could see that the counter is still at N, because your-  laptop had the file last time it was online, and can decide to drop the file, and lose the last -version.--- pushing a changed counter commit to other repos is tricky, because they're not bare, and -  the network topology to get the commit pulled into the other repo could vary.--- Merging counter files issues.  If the counter file doesn't automerge, two repos dropping the same file will conflict. But, if it does automerge, it breaks the counter conflict detection.--- Needing to revert commits is going to be annoying. An actual git revert-  could probably not reliably be done. It's need to construct a revert-  and commit it as a new commit. And then try to push that to remotes, and-  what if *that* push conflicts?--- I do like the pre-removal dropping somewhat as an alternative to-  trust checking. I think that can be done with current git-annex though,-  just remove the files from the location log, but keep them in-annex.-  Dropping a file only looks at repos that the location log says have a-  file; so other repos can have retained a copy of a file secretly like-  this, and can safely remove it at any time. I'd need to look into this a bit more to be 100% sure it's safe, but have started [[todo/hidden_files]]. --- I don't see any reduced round trips. It still has to contact N other-  repos on drop. Now, rather than checking that they have a file, it needs-  to push a change to them.-"""]]
− doc/forum/relying_on_git_for_numcopies/comment_2_be6acbc26008a9cb54e7b8f498f2c2 
@@ -1,18 +0,0 @@-[[!comment format=mdwn- username="http://christian.amsuess.com/chrysn"- nickname="chrysn"- subject="comment 2"- date="2011-02-23T16:43:59Z"- content="""-i'll comment on each of the points separately, well aware that even a single little leftover issue can show that my plan is faulty:--* force removal: well, yes -- but the file that is currently force-removed on the laptop could just as well be the last of its kind itself. i see the problem, but am not sure if it's fatal (after all, if we rely on out-of-band knowledge when forcing something, we could just as well ask a little more)-* non-bare repos: pushing is tricky with non-bare repos now just as well; a post-commit hook could auto-accept counter changes. (but pushing causes problems with counters anyway, doesn't it?)-* merging: i'd have them auto-merge. git-annex will have to check the validity of the current state anyway, and a situation in which a counter-decrementing commit is not a fast-forward one would be reverted in the next step (or upon discovery, in case the next step never took place).-* reverting: my wording was bad as \"revert\" is already taken in git-lingo. the correct term for what i was thinking of is \"reset\". (as the commit could not be pushed, it would be rolled back completely).-    * we might have to resort to reverting, though, if the commit has already been pused to a first server of many.-* [[todo/hidden files]]: yes, this solves pre-removal dropping :-)-* round trips: it's not the number of servers, it's the number of files (up to 30k in my case). it seems to me that an individual request was made for every single file i wanted to drop (that would be N*M roundtrips for N affected servers and M files, and N roundtrips with git managed numcopies)--all together, it seems to be a bit more complicated than i imagined, although not completely impossible. a combination of [[todo/hidden files]] and maybe a simpler reduction of the number of requests might though achieve the important goals as well.-"""]]
− doc/forum/relying_on_git_for_numcopies/comment_3_43d8e1513eb9947f8a503f094c03f3 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://christian.amsuess.com/chrysn"- nickname="chrysn"- subject="relation to [[todo/branching]]"- date="2011-02-23T21:48:14Z"- content="""-the non-bare repository issue would go away if this was combined with the \"alternate\" approach to [[todo/branching]]. (with the \"fleshed out proposal\" of branching, this would not work at all for lack of shared commits.)-"""]]
− doc/forum/retrieving_previous_versions/comment_1_a4e83f688d4ec9177e7bf520f12ed2 
@@ -1,11 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-04-24T21:14:15Z"- content="""-To get to a specific version of a file, you need to have a tag or a branch that includes that version of the file. Check out the branch and `git annex get $file`. --(Of course, even without a tag or branch, old file versions are retained, unless dropped with `unused`/`dropunused`.-So you could even `git checkout $COMMITID`.)-"""]]
− doc/forum/rsync_over_ssh__63__/comment_1_ee21f32e90303e20339e0a568321bbbe._comm 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-03-06T15:59:37Z"- content="""-Everything is done over ssh unless both repos are on the same system (or unless you NFS mount a repo)-"""]]
− doc/forum/rsync_over_ssh__63__/comment_2_aa690da6ecfb2b30fc5080ad76dc77b1._comm 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://m-f-k.myopenid.com/"- ip="92.194.43.135"- subject="comment 2"- date="2011-03-06T16:33:19Z"- content="""-Great! This was the only thing about git-annex which could have kept me from using it. --Michael-"""]]
− doc/forum/sparse_git_checkouts_with_annex/comment_1_c7dc199c5740a0e7ba606dfb5e3 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-04-07T16:32:04Z"- content="""-That's awesome, I had not heard of git sparse checkouts before. --It does not make sense to tie the log files to the directory of the corresponding files, as then the logs would have to move when the files are moved, which would be a PITA and likely make merging log file changes very complex. Also, of course, multiple files in different locations can point at the same content, which has the same log file. And, to cap it off, git-annex can need to access the log file for a given key without having the slightest idea what file in the repository might point to it, and it would be very expensive to scan the whole repository to find out what that file is in order to lookup the filename of the log file.--The most likely change in git-annex that will make this better is in [[this_todo_item|todo/branching]] -- but it's unknown how to do it yet.-"""]]
− doc/forum/sparse_git_checkouts_with_annex/comment_2_e357db3ccc4079f07a291843975 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-04-07T16:33:30Z"- content="""-BTW, git-annex unused *will* have a problem that not all the symlinks are present. It will suggest dropping content belonging to the excluded symlinks.-"""]]
− doc/forum/sparse_git_checkouts_with_annex/comment_3_fcfafca994194d57dccf5319c7c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"- nickname="Christian"- subject="comment 3"- date="2011-04-08T07:31:03Z"- content="""-So perhaps checking if git-status (or similar) complains about missing files is a possible solution for this?-"""]]
− doc/forum/sparse_git_checkouts_with_annex/comment_4_04dc14880f31eee2b6d767d4d42 
@@ -1,20 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"- nickname="Christian"- subject="comment 4"- date="2011-04-08T07:54:37Z"- content="""-And something else i've done is, that i symlinked the video/ directory from the media annex to the normal raid annex--    ln -s ~/media/annex/video ~/annex--And it's working out great.--    ~annex $ git annex whereis video/series/episode1.avi-    whereis video/series/episode1.avi(1 copy)-        	f210b45a-60d3-11e0-b593-3318d96f2520  -- Trantor - Media-    ok--I really like this, perhaps it is a good idea to store all log files in every repo, but maybe there is a possibilitiy to to pack multiple log files into one single file, where not only the time, the present bit and the annex-repository is stored, but also the file key. I don't know if this format would also be merged correctly by the union merge driver.--"""]]
− doc/forum/unannex_alternatives/comment_1_dcd4cd41280b41512bbdffafaf307993._comm 
@@ -1,46 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-02-02T00:39:10Z"- content="""-Git-annex's commit hook does not prevent unannex being used. The file you unannex will not be checked into git anymore and will be a regular file again, not a git-annex symlink. --For example, here's a transcript:--<pre>-joey@gnu:~/tmp>mkdir demo-joey@gnu:~/tmp>cd demo-joey@gnu:~/tmp/demo>git init-Initialized empty Git repository in /home/joey/tmp/demo/.git/-joey@gnu:~/tmp/demo>git annex init demo-init demo ok-joey@gnu:~/tmp/demo>echo hi > file-joey@gnu:~/tmp/demo>git annex add file -add file ok-(Recording state in git...)-joey@gnu:~/tmp/demo>git commit -m add-[master 64cf267] add- 2 files changed, 2 insertions(+), 0 deletions(-)- create mode 100644 .git-annex/WORM:1296607093:3:file.log- create mode 120000 file-joey@gnu:~/tmp/demo>git annex unannex file-unannex file ok-(Recording state in git...)-joey@gnu:~/tmp/demo>ls -l file--rw-r--r-- 1 joey joey 3 Feb  1 20:38 file-joey@gnu:~/tmp/demo>git commit-[master 78a09cc] unannex- 2 files changed, 1 insertions(+), 2 deletions(-)- delete mode 120000 file-joey@gnu:~/tmp/demo>ls -l file--rw-r--r-- 1 joey joey 3 Feb  1 20:38 file-joey@gnu:~/tmp/demo>git status-# On branch master-# Untracked files:-#   (use \"git add <file>...\" to include in what will be committed)-#-#	file-nothing added to commit but untracked files present (use \"git add\" to track)-</pre>-"""]]
− doc/forum/unannex_alternatives/comment_2_58a72a9fe0f58c7af0b4d7927a2dd21d._comm 
@@ -1,36 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-02-02T00:41:24Z"- content="""-And following on to my transcript, you can then add the file to git in the regular git way, and it works fine:--<pre>-joey@gnu:~/tmp/demo>git add file-joey@gnu:~/tmp/demo>git commit-[master 225ffc0] added as regular git file, not in annex- 1 files changed, 1 insertions(+), 0 deletions(-)- create mode 100644 file-joey@gnu:~/tmp/demo>ls -l file--rw-r--r-- 1 joey joey 3 Feb  1 20:38 file-joey@gnu:~/tmp/demo>git log file-commit 225ffc048f5af7c0466b3b1fe549a6d5e9a9e9fe-Author: Joey Hess <joey@kitenet.net>-Date:   Tue Feb 1 20:43:13 2011 -0400--    added as regular git file, not in annex--commit 78a09cc791b875c3b859ca9401e5b6472bf19d08-Author: Joey Hess <joey@kitenet.net>-Date:   Tue Feb 1 20:38:30 2011 -0400--    unannex--commit 64cf267734adae05c020d9fd4d5a7ff7c64390db-Author: Joey Hess <joey@kitenet.net>-Date:   Tue Feb 1 20:38:18 2011 -0400--    add-</pre>-"""]]
− doc/forum/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comm 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-02-02T00:46:00Z"- content="""-Sorry for all the followups, but I see now that if you unannex, then add the file to git normally, and commit, the hook *does* misbehave.--This seems to be a bug. git-annex's hook thinks that you have used git annex unlock (or \"git annex edit\") on the file and are now committing a changed version, and the right thing to do there is to add the new content to the annex and update the symlink accordingly. I'll track this bug over at [[bugs/unannex_vs_unlock_hook_confusion]].--So, committing after unannex, and before checking the file into git in the-usual way, is a workaround. But only if you do a "git commit" to commit-staged changes.--Anyway, this confusing point is fixed in git now!-"""]]
− doc/forum/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb5978 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-01-07T17:15:31Z"- content="""-Well, lock could check for modifications and require --force to lose them. But the check could be expensive for large files.--But `git annex lock` is just a convenient way to run `git checkout`. And running `git checkout` or `git reset --hard` will lose your uncommitted file the same way obviously. --Perhaps the best fix would be to get rid of `lock` entirely, and let the user use the underlying git commands same as they would to drop modifications to other files. It would then also make sense to remove `unlock`, leaving only `edit`.-"""]]
− doc/forum/using_git_annex_to_merge_and_synchronize_2_directories___40__like_uni 
@@ -1,7 +0,0 @@-I would like to use git-annex to synchronize 2 directories in the same manner as unison.--I'm starting with 2 directories. There is an overlap of the same set of files in each directory, but each directory also has additional files as well.--I create a git annex in each directory but when I do a git pull it merges and produces conflicts on those files that are the same.--What is the correct workflow for this type of scenario?
− doc/forum/version_3_upgrade/comment_1_05fc9c9cad26c520bebb98c852c71e35._comment 
@@ -1,13 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-08-17T01:33:08Z"- content="""-It's ok that `git pull` does not merge the git-annex branch. You can merge it with `git annex merge`, or it will be done-automatically when you use other git-annex commands.--If you use `git pull` and `git push` without any options, the defaults will make git pull and push the git-annex branch automatically.--But if you're in the habit of doing `git push origin master`, that won't cause the git-annex branch to be pushed (use `git push origin git-annex` to manually push it then). Similarly, `git pull origin master` won't pull it. And also, the `remote.origin.fetch` setting in `.git/config` can be modified in ways that make `git pull` not automatically pull the git-annex branch. So those are the things to avoid after upgrade to v3, basically.-"""]]
− doc/forum/vlc_and_git-annex/comment_1_9c9ab8ce463cf74418aa2f385955f165._comment 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2011-12-23T16:16:19Z"- content="""-From what you say, it seems that vlc is following the symlink to the movie content, and then looking for subtitles next to the file the symlink points to. It would have to explicitly realpath the symlink to have this behavior, and this sounds like a misfeature.. perhaps you could point out to the vlc people the mistake in doing so?--There's a simple use-case where this behavior is obviously wrong, without involving git-annex. Suppose I have a movie, and one version of subtitles for it, in directory `foo`. I want to modify the subtitles, so I make a new directory `bar`, symlink the large movie file from `foo` to save space, and copy over and edit the subtitles from `foo`. Now I run vlc in `bar` to test my new subtitles. If it ignores the locally present subtitles and goes off looking for the ones in `bar`, I say this is broken behavior.-"""]]
− doc/forum/vlc_and_git-annex/comment_2_037f94c1deeac873dbdb36cd4c927e45._comment 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-12-23T18:43:05Z"- content="""-Since subtitle files are typically pretty small, a workaround is to simply check them into git directly, and only use git-annex for the movies. (Or `git annex unannex` the ones you've already annexed.)-"""]]
− doc/forum/windows_port__63__/comment_1_23fa9aa3b00940a1c1b3876c35eef019._commen 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 1"- date="2012-03-12T06:43:02Z"- content="""-[[todo/windows_support]] has everything I know about making a windows port. This badly needs someone who understand Windows to dive into it. The question of how to create a symbolic link (or the relevant Windows equivilant) from haskell on Windows-is a good starting point..-"""]]
− doc/forum/wishlist:_command_options_changes/comment_1_bfba72a696789bf21b2435dea 
@@ -1,17 +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-04-17T23:46:37Z"- content="""---to and --from seem to have different semantics than --source and --destination. Subtle, but still different.--That being said, I am not sure --from and --to are needed at all. Calling the local repo . and all remotes by their name, they are arguably redundant and removing them would make the syntax a lot prettier; mv and cp don't need them, either.--I am not sure changing syntax at this point is considered good style though personally, I wouldn't mind adapting and would actually prefer it over using --to and --from.---v and -q would be nice.---Richard-"""]]
− doc/forum/wishlist:_command_options_changes/comment_2_f6a637c78c989382e3c22d41b 
@@ -1,19 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-04-19T20:13:10Z"- content="""-Let's see..--* -v is already an alias for --verbose--* I don't find --source and --destination as easy to type or as clear as --from or --to.--* -F is fast, so it cannot be used for --force. And I have no desire to make it easy to mistype a short option and enable --force; it can lose data. --@richard while it would be possible to support some syntax like \"git annex copy . remote\"; what is it supposed to do if there are local files named foo and bar, and a remotes named foo and bar? Does \"git annex copy foo bar\" copy file foo to remote bar, or file bar from remote foo? I chose to use --from/--to to specify remotes independant of files to avoid such-ambiguity, which plain old `cp` doesn't have since it's operating entirely on filesystem objects, not both filesystem objects and abstract remotes.--Seems like nothing to do here. [[done]] --[[Joey]]-"""]]
− doc/forum/wishlist:_command_options_changes/comment_3_bf1114533d2895804e531e76e 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 3"- date="2011-04-20T21:28:06Z"- content="""-Good point. scp fixes this by using a colon, but as colons aren't needed in git-annex remotes' names... -- RichiH-"""]]
− doc/forum/wishlist:_git-annex_replicate/comment_1_9926132ec6052760cdf28518a24e2 
@@ -1,10 +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-04-22T18:27:00Z"- content="""-While having remotes redistribute introduces some obvious security concerns, I might use it.--As remotes support a cost factor already, you can basically implement bandwidth through that.-"""]]
− doc/forum/wishlist:_git-annex_replicate/comment_2_c43932f4194aba8fb2470b18e0817 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-04-23T16:22:07Z"- content="""-Besides the cost values, annex.diskreserve was recently added. (But is not available for special remotes.)--I have held off on adding high-level management stuff like this to git-annex, as it's hard to make it generic enough to cover use cases.--A low-level way to accomplish this would be to have a way for `git annex get` and/or `copy` to skip files when `numcopies` is already satisfied. Then cron jobs could be used.-"""]]
− doc/forum/wishlist:_git-annex_replicate/comment_3_c13f4f9c3d5884fc6255fd04feadc 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"- nickname="Justin"- subject="comment 3"- date="2011-04-23T17:54:42Z"- content="""-Hmm, so it seems there is almost a way to do this already.--I think the one thing that isn't currently possible is to have 'plain' ssh remotes.. basically something just like the directory remote, but able to take a ssh user@host/path url.  something like sshfs could be used to fake this, but for things like fsck you would want to do the sha1 calculations on the remote host.-"""]]
− doc/forum/wishlist:_git-annex_replicate/comment_4_63f24abf086d644dced8b01e1a994 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-09-19T18:54:46Z"- content="""-git annex get/copy/drop all now support a --auto flag, which makes them only act on files that have not enough or too many copies. This allows for some crude replication; it doesn't take into account which repositories should be filled up more (beyond honoring annex.diskreserve), nor does it try to optimally use bandwidth (beyond honoring configured annex-cost). You have to run it in every repository that you want to participate in the replication, too. But it's probably a Good Enough solution. See [[walkthrough/automatically_managing_content]].-"""]]
− doc/forum/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 1"- date="2011-04-08T07:23:08Z"- content="""-+1 for this feature, I've been longing for something like this other than rolling my own perl/shell scripts to parse the outputs of \"git annex whereis .\" to see how many files are on my machine or not.-"""]]
− doc/forum/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824 
@@ -1,13 +0,0 @@-[[!comment format=mdwn- username="http://christian.amsuess.com/chrysn"- nickname="chrysn"- subject="format, respect working directory"- date="2011-04-26T12:31:02Z"- content="""-we could include the information about the current directory as well, if the command is not issued in the local git root directory. to avoid large numbers of similar lines, that could look like this:--    Estimated annex size: B MiB (of C MiB; [B/C]%)-    Estimated annex size in $PWD: B' MiB (of C' MiB; [B'/C']%)--with the percentages being replaced with \"complete\" if really all files are present (and not just many enough for the value to be rounded to 100%).-"""]]
− doc/forum/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7 
@@ -1,23 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2011-05-17T01:15:10Z"- content="""-What a good idea!--150 lines of haskell later, I have this:--<pre>-# git annex status-supported backends: WORM SHA1 SHA256 SHA512 SHA224 SHA384 SHA1E SHA256E SHA512E SHA224E SHA384E URL-supported remote types: git S3 bup directory rsync hook-local annex keys: 32-local annex size: 58 megabytes-total annex keys: 38158-total annex size: 6 terabytes (but 1632 keys have unknown size)-backend usage: -	SHA1: 1789-	WORM: 36369-</pre>-"""]]
− doc/forum/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://christian.amsuess.com/chrysn"- nickname="chrysn"- subject="status of other remotes?"- date="2011-06-15T08:39:24Z"- content="""-using the location tracking information, it should be possible to show the status of other remotes as well. what about supporting `--from=...` or `--all`? (thus, among other things, one could determine if a remote has a complete checkout.)-"""]]
− doc/forum/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_ 
@@ -1,1 +0,0 @@-I just added a CIA bot to #vcs-home and tracking commits immediately would be nice. -- RichiH
− doc/forum/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c 
@@ -1,19 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"- nickname="Justin"- subject="comment 1"- date="2012-04-29T01:41:57Z"- content="""-Thinking about this more, I think minimally git-annex could support a--    remote.<name>.gpg-options--or--    remote.<name>.gpg-keyring--for options to be passed to gpg.  I'm not sure how automatically setting it to $ANNEX_ROOT/.gnupg/.. would work.---I need to read the encryption code to fully understand it, but I also wonder if there is not also a way to just bypass gpg entirely and store the remote-encryption keys locally in plain text.-"""]]
− doc/forum/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2012-04-29T02:39:20Z"- content="""-The encryption uses a symmetric cipher that is stored in the git repository already. It's just stored encrypted to the various gpg keys that have been configured to use it. It would certianly be possible to store the symmetric cipher unencrypted in the git repo. --I don't see your idea of gpg-options saving any work. It would still require you to do key distribution and run commands in each repo to set it up.-"""]]
− doc/forum/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dab 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 3"- date="2012-04-29T02:41:38Z"- content="""-BTW re your Tweet.. I was so happy to be able to use 'c i a' in Crypto.hs. :)-"""]]
− doc/forum/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661e 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawmBUR4O9mofxVbpb8JV9mEbVfIYv670uJo"- nickname="Justin"- subject="comment 4"- date="2012-04-29T03:09:03Z"- content="""-I got a good laugh out of it :-)--Storing the key unencrypted would make things easier..  I think at least for my use-cases I don't require another layer of protection on top of the ssh keys that provide access to the encrypted remotes themselves.-"""]]
− doc/forum/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 5"- date="2012-04-29T18:04:13Z"- content="""-encryption=shared is now supported-"""]]
− doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._co 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://adamspiers.myopenid.com/"- nickname="Adam"- subject="Cool"- date="2011-12-23T19:16:50Z"- content="""-Very nice :)  Just for reference, here's [my Perl implementation](https://github.com/aspiers/git-config/blob/master/bin/git-annex-finddups).  As per [this discussion](http://git-annex.branchable.com/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates/#comment-fb15d5829a52cd05bcbd5dc53edaffb2) it would be interesting to benchmark these two approaches and see if one is substantially more efficient than the other w.r.t. CPU and memory usage.-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="http://www.openid.albertlash.com/openid/"- ip="71.178.29.218"- subject="comment 1"- date="2011-12-24T06:08:45Z"- content="""-Looks like you are missing a closing double quote on the line:---echo '$GL_ADC_PATH = \"/usr/local/lib/gitolite/adc/;' >>~gitolite/.gitolite.rc--right after /;--I got this working by the way - great stuff.-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecef 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-12-24T16:54:31Z"- content="""-I've fixed the typo (anyone can edit pages in this wiki FWIW.)-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd374 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="bremner"- ip="156.34.79.193"- subject="repo name conventions?"- date="2011-12-30T21:41:13Z"- content="""-I'm confused by the fact that the git-annex-shell adc rejects any repo names that don't start with /~/ since none of my repos start that way. It seems work ok if I just delete /\~ from the front of the regex, but I feel like I must be missing something. -"""]]
− doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba 
@@ -1,33 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-12-31T00:29:45Z"- content="""-Well a repo url like `gitolite@localhost:testing` puts it in the gitolite user's /~/testing--This worked when I added the gitolite stuff, anyway.. Let's see if it still does:--<pre>-joey@gnu:~/tmp>mkdir g-joey@gnu:~/tmp>cd g-joey@gnu:~/tmp/g>git init-Initialized empty Git repository in /home/joey/tmp/g/.git/-joey@gnu:~/tmp/g>git annex init-init  ok-joey@gnu:~/tmp/g>git remote add test 'gitolite@localhost:testing'-joey@gnu:~/tmp/g>touch foo-joey@gnu:~/tmp/g>git annex add foo-add foo (checksum...) ok-(Recording state in git...)-joey@gnu:~/tmp/g>git annex copy foo --to test --debug-git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"ls-files\",\"--cached\",\"-z\",\"--\",\"foo\"]-git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"check-attr\",\"annex.numcopies\",\"-z\",\"--stdin\"]-git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"show-ref\",\"--hash\",\"refs/heads/git-annex\"]-git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"show-ref\",\"git-annex\"]-git [\"--git-dir=/home/joey/tmp/g/.git\",\"--work-tree=/home/joey/tmp/g\",\"cat-file\",\"--batch\"]-Running: ssh [\"-4\",\"gitolite@localhost\",\"git-annex-shell 'configlist' '/~/testing'\"]-</pre>--Still seems right, the ADC's regexp will match this the git-annex shell command.-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c 
@@ -1,20 +0,0 @@-[[!comment format=mdwn- username="bremner"- ip="156.34.79.193"- subject="gitolite gets different paths for different urls"- date="2011-12-31T01:50:49Z"- content="""-I guess there is some path rewriting going in in gitolite proper because if try a url of the form -ssh://git@localhost/testing, then it still works with gitolite, but fails with the ADC because -the repo is passed as /testing:-<pre>-Running: ssh [\"git@host\",\"git-annex-shell 'configlist' '/recommend'\"]-Running: ssh [\"git@host\",\"git-annex-shell 'configlist' '/recommend'\"]-</pre>--What I have to ask Sitaram and or find in the docs is if this is a bug or a feature in gitolite.  I can see how the leading slash would get swallowed up by this line -<pre>-$repo = \"'$REPO_BASE/$repo.git'\"-</pre>-in gl-auth-command, but I guess that isn't the whole story.-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718ad 
@@ -1,25 +0,0 @@-[[!comment format=mdwn- username="bremner"- ip="156.34.79.193"- subject="ssh://gitolite-host/repo-name is supposed to work"- date="2011-12-31T03:34:17Z"- content="""-I confirmed with Sitaram that this is intentional, if probably under-documented.-Since the ADC strips the leading /~/ in assigning $start anyway, I guess something like the following will  work -<pre>--diff --git a/contrib/adc/git-annex-shell b/contrib/adc/git-annex-shell-index 7f9f5b8..523dfed 100755---- a/contrib/adc/git-annex-shell-+++ b/contrib/adc/git-annex-shell-@@ -28,7 +28,7 @@ my $cmd=$ENV{SSH_ORIGINAL_COMMAND};- # the second parameter.- # Further parameters are not validated here (see below).- die \"bad git-annex-shell command: $cmd\"--    unless $cmd =~ m#^(git-annex-shell '\w+' ')/\~/([0-9a-zA-Z][0-9a-zA-Z._\@/+--+    unless $cmd =~ m#^(git-annex-shell '\w+' ')/(?:\~\/)?([0-9a-zA-Z][0-9a-zA-Z.- my $start = $1;- my $repo = $2;- my $end = $3;-</pre>-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c8734805722 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 7"- date="2011-12-31T18:32:28Z"- content="""-That patch seems ok, it doesn't seem to allow through any repo locations that were blocked before.--So, it has my blessing.. but the ADC is in gitolite and will need to be patched there.-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa9 
@@ -1,29 +0,0 @@-[[!comment format=mdwn- username="bremner"- ip="156.34.79.193"- subject="afaict git annex normalizes urls on the client side."- date="2011-12-31T22:29:38Z"- content="""-After some debugging printing, here is my current understanding.--- urls of the form git@host:~repo or ssh://git@host--  - git sends commands like  \"git-receive-pack '~/repo'-  - gitolite converts these to $REPO_BASE/~/repo which fails.  ~/repo would also fail fwiw.-  - git-annex sends seems /~/repo, which works--- urls of the form git@host:/repo or ssh://git@host/repo--  - git sends \"git-receive-pack '/db/cs3383'\"-  - gitolite converts this to $REPO_BASE/repo which works-  - git annex sends \"git-annex-shell 'inannex' '/repo' ...\" which works, but only with the patch above.--- urls of the form git@host:repo--  - git sends \"git-receive-pack 'repo'-  - gitolite converts this to $REPO_BASE/repo, which works-  - git-annex sends \"git-annex-shell 'inannex' '/~/db/cs3383'...\", which also works for git-annex-shell.--So the weird case is the last one where git and git-annex are sending different things over the wire.-I don't know if you have other motivations for doing the url normalization on the client side, but it isn't needed for gitolite, and in some sense complicates things a little.  On the other hand, now that I see what is going on, it isn't a big deal to just strip the leading /~ off in the adc. It does lead to the odd situation of some URLs working for git-annex but not git.-"""]]
− doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c2 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 9"- date="2012-01-02T16:27:55Z"- content="""-Ah right. git-annex normalizes all git ssh style user@host:dir to valid uris, which is where the `/~/` comes from. I don't anticipate this changing on the git-annex side.-"""]]
− doc/todo/git_annex_init_:_include_repo_description_and__47__or_UUID_in_commit_m 
@@ -1,13 +0,0 @@-Would help alot when having to add large(ish) amounts of remotes.--Maybe detect this kind of commit message and ask user whether to automatically add them? See [[auto_remotes]]:-> Question: When should git-annex update the remote.log? (If not just on init.) Whenever it reads in a repo's remotes?--------I'm not sure that the above suggestion is going down a path that really-makes sense. If you want a list of repository UUIDs and descriptions,-it's there in machine-usable form in `.git-annex/uuid.log`, there is no-need to try to pull this info out of git commit messages. --[[Joey]]--[[done]]
− doc/todo/object_dir_reorg_v2/comment_1_ba03333dc76ff49eccaba375e68cb525._commen 
@@ -1,8 +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-03-16T01:16:48Z"- content="""-If you support generic meta-data, keep in mind that you will need to do conflict resolution. Timestamps may not be synched across all systems, so keeping a log of old metadata could be used, sorting by history and using the latest. Which leaves the situation of two incompatible changes. This would probably mean manual conflict resolution. You will probably have thought of this already, but I still wanted to make sure this is recorded. -- RichiH-"""]]
− doc/todo/object_dir_reorg_v2/comment_2_81276ac309959dc741bc90101c213ab7._commen 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 2"- date="2011-03-16T01:19:25Z"- content="""-Hmm, I added quite a few comments at work, but they are stuck in moderation. Maybe I forgot to log in before adding them. I am surprised this one appeared immediately. -- RichiH-"""]]
− doc/todo/object_dir_reorg_v2/comment_3_79bdf9c51dec9f52372ce95b53233bb2._commen 
@@ -1,12 +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-03-15T14:08:41Z"- content="""-What is the potential time-frame for this change? As I am not using git-annex for production yet, I can see myself waiting to avoid any potential hassle.--Supporting generic metadata seems like a great idea. Though if you are going this path, wouldn't it make sense to avoid metastore for mtime etc and support this natively without outside dependencies?---- RichiH-"""]]
− doc/todo/object_dir_reorg_v2/comment_4_93aada9b1680fed56cc6f0f7c3aca5e5._commen 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-03-16T03:22:45Z"- content="""-Well, I spent a few hours playing this evening in the 'reorg' branch in git. It seems to be shaping up pretty well; type-based refactoring in haskell makes these kind of big systematic changes a matter of editing until it compiles. And it compiles and test suite passes. But, so far I've only covered 1. 3. and 4. on the list, and have yet to deal with upgrades.--I'd recommend you not wait before using git-annex. I am committed to provide upgradability between annexes created with all versions of git-annex, going forward. This is important because we can have offline archival drives that sit unused for years. Git-annex will upgrade a repository to current standard the first time it sees it, and I hope the upgrade will be pretty smooth. It was not bad for the annex.version 0 to 1 upgrade earlier. The only annoyance with upgrades is that it will result in some big commits to git, as every symlink in the repo gets changed, and log files get moved to new names.--(The metadata being stored with keys is data that a particular backend can use, and is static to a given key, so there are no merge issues (and it won't be used to preserve mtimes, etc).)-"""]]
− doc/todo/object_dir_reorg_v2/comment_5_821c382987f105da72a50e0a5ce61fdc._commen 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 5"- date="2011-03-16T15:51:30Z"- content="""-Hashing & segmenting seems to be around the corner, which is nice :)--Is there a chance that you will optionally add mtime to your native metadata store? If yes, I'd rather wait for v2 to start with the native system from the start. If not, I will probably set it up tonight.--PS: While posting from work, my comments are held for moderation once again. I am somewhat confused as to why this happens when I can just submit directly from home. And yes, I am using the same auth provider and user in both cases.-"""]]
− doc/todo/object_dir_reorg_v2/comment_6_8834c3a3f1258c4349d23aff8549bf35._commen 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 6"- date="2011-03-16T16:32:52Z"- content="""-The mtime cannot be stored for all keys. Consider a SHA1 key. The mtime is irrelevant; 2 files with different mtimes, when added to the SHA1 backend, should get the same key.--Probably our spam filter doesn't like your work IP.-"""]]
− doc/todo/object_dir_reorg_v2/comment_7_42501404c82ca07147e2cce0cff59474._commen 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 7"- date="2011-03-16T21:05:38Z"- content="""-Ah, OK. I assumed the metadata would be attached to a key, not part of the key. This seems to make upgrades/extensions down the line harder than they need to be, but you are right that this way, merges are not, and never will be, an issue.--Though with the SHA1 backend, changing files can be tracked. This means that tracking changes in mtime or other is possible. It also means that there are potential merge issues. But I won't argue the point endlessly. I can accept design decisions :)--The prefix at work is from a university netblock so yes, it might be on a few hundred proxy lists etc.-"""]]
− doc/todo/parallel_possibilities/comment_1_d8e34fc2bc4e5cf761574608f970d496._com 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkptNW1PzrVjYlJWP_9e499uH0mjnBV6GQ"- nickname="Christian"- subject="comment 1"- date="2011-04-08T12:41:43Z"- content="""-I also think, that fetching keys via rsync can be done by one rsync process, when the keys are fetched from one host. This would avoid establishing a new TCP connection for every file.-"""]]
− doc/todo/parallel_possibilities/comment_2_adb76f06a7997abe4559d3169a3181c3._com 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://ertai.myopenid.com/"- nickname="npouillard"- subject="comment 2"- date="2011-05-20T20:14:15Z"- content="""-I agree with Christian.--One should first make a better use of connections to remotes before exploring parallel possibilities. One should pipeline the requests and answers.--Of course this could be implemented using parallel&concurrency features of Haskell to do this.-"""]]
− doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._commen 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="zooko"- ip="97.118.97.117"- subject="performance"- date="2011-05-17T19:20:39Z"- content="""-Hm... O(N^2)? I think it just takes O(N). To read an entry out of a directory you have to download the entire directory (and store it in RAM and parse it). The constants are basically \"too big to be good but not big enough to be prohibitive\", I think. jctang has reported that his special remote hook performs well enough to use, but it would be nice if it were faster.--The Tahoe-LAFS folks are working on speeding up mutable files, by the way, after which we would be able to speed up directories.-"""]]
− doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._commen 
@@ -1,13 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-05-17T19:57:33Z"- content="""-Whoops! You'd only told me O(N) twice before..--So this is not too high priority. I think I would like to get the per-remote storage sorted out anyway, since probably it will be the thing needed to convert the URL backend into a special remote, which would then allow ripping out the otherwise unused pluggable backend infrastructure.--Update: Per-remote storage is now sorted out, so this could be implemented-if it actually made sense to do so.-"""]]
− doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_dupli 
@@ -1,28 +0,0 @@-(Hi, this is paulproteus@debian, AKA Asheesh).--I've been enjoying using git-annex to archive my data.--It's great that, by using git-annex and the SHA1 backend, I get a space-saving kind of deduplication through the symbolic links.--I'm looking for the ability to filter files, before they get added to the annex, so that I don't add new files whose content is already in the annex.look  That would help me in terms of personal file organization.--It seems there is not, so this is a wishlist bug filed so that maybe such a thing might exist. What I would really like to do is:--* $ git annex add --no-add-if-already-present .-* $ git commit -m "Slurping in some photos I found on my old laptop hard drive"--And then I'd do something like:--* $ git clean -f--to remove the files that didn't get annexed in this run. That way, only one filename would ever point to a particular SHA1.--I want this because I have copies of various of mine (photos, in particular) scattered across various hard disks. If this feature existed, I could comfortably toss them all into one git annex that grew, bit by bit, to store all of these files exactly once.--(I would be even happier for "git annex add --unlink-duplicates .")--(Another way to do this would be to "git annex add" them all, and then use a "git annex remove-duplicates" that could prompt me about which files are duplicates of each other, and then I could pipe that command's output into xargs git rm.)--(As I write this, I realize it's possible to parse the destination of the symlink in a way that does this..)--> [[done]]; see [[tips/finding_duplicate_files]] --[[Joey]]
− doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote. 
@@ -1,12 +0,0 @@-The [Web special remote](http://git-annex.branchable.com/special_remotes/web/) could possibly be improved by detecting when URLs reference a Youtube video page and using [youtube-dl](http://rg3.github.com/youtube-dl/) instead of wget to download the page. Youtube-dl can also handle several other video sites such as vimeo.com and blip.tv, so if this idea were to be implemented, it might make sense to borrow the regular expressions that youtube-dl uses to identify video URLs. A quick grep through the youtube-dl source for the identifier _VALID_URL should find those regexes (in Python's regex format).--> This is something I've thought about doing for a while.. -> Two things I have not figured out:-> -> * Seems that this should really be user-configurable or a plugin system,->   to handle more than just this one case.-> * Youtube-dl breaks from time to time, I really trust these urls a lot->   less than regular urls. Perhaps per-url trust levels are called for by->   this.-> -> --[[Joey]]
− doc/todo/wishlist:_swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._co 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"- nickname="Jimmy"- subject="comment 1"- date="2011-05-14T10:04:36Z"- content="""-I don't suppose this SWIFT api is compatible with the eucalytpus walrus api ?-"""]]
− doc/todo/wishlist:_swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._co 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"- nickname="Richard"- subject="comment 2"- date="2011-05-14T15:00:51Z"- content="""-It does offer a S3 compability layer, but that is de facto non-functioning as of right now.-"""]]
− doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._com 
@@ -1,8 +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-03-19T01:18:49Z"- content="""-After doing the above with two required copy per file, `git annex fsck` complained that I had only one copy per file even though I had created my clone, already. Once I `git pull`ed from the second repo, not getting any changes for obvious reasons, `git annex fsck` was happy. So I am not sure how my addition was incorrect. -- RichiH-"""]]
− doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._com 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-03-19T15:35:38Z"- content="""-Yes, you have to pull down location tracking information in order for fsck to be satisfied in that situation. But since this is a walkthrough, and neither fsck or numcopies settings are mentioned until later, it's ok for this pull to be described a few steps along in [[getting file content]].--"""]]
− doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._com 
@@ -1,9 +0,0 @@-[[!comment format=mdwn- username="http://dieter-be.myopenid.com/"- nickname="dieter"- subject="comment 3"- date="2011-04-02T20:24:33Z"- content="""- * why the `git remote add laptop ~/annex` ? this remote already exists under the name origin.- * doesn't the last command need to be `git remote add usbdrive /media/usb/annex`? because the actual repo would be in /media/usb/annex, not /media/usb?-"""]]
− doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._com 
@@ -1,10 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 4"- date="2011-04-03T02:32:17Z"- content="""-Good spotting on the last line, fixed.--The laptop remote is indeed redundant, but it leads to clearer views of what is going on later in the walkthrough (\"git pull laptop master\", \"(copying from laptop...)\"). And if the original clone is made from a central bare repo, this reinforces that you'll want to set up remotes for other repos on the computer.-"""]]
− doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comm 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="DavidEdmondson"- subject="Is it necessary to commit after the 'drop'?"- date="2011-09-05T15:43:25Z"- content="""-In fact is it possible? Nothing changed as far as git is concerned.--"""]]
− doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comm 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joey.kitenet.net/"- nickname="joey"- subject="comment 2"- date="2011-09-05T15:59:27Z"- content="""-Good catch. It used to be necessary before there was a git-annex branch, but not now.-"""]]
− doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._c 
@@ -1,13 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.81.112"- subject="comment 2"- date="2012-05-27T20:53:05Z"- content="""-When `git annex get` does nothing, it's because it doesn't know a place to get the file from.--This can happen if the `git-annex` branch has not propigated from the place where the file was added.-For example, if on the laptop you had run `git pull ssh master`, that would only pull the master branch, not the git-annex branch. --An easy way to ensure the git-annex branch is kept in sync is to run `git annex sync`-"""]]
− doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._c 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"- nickname="Fernando Seabra"- subject="cannot get files"- date="2012-05-27T20:33:09Z"- content="""-Hi,--I could successfully clone my ssh repo's annex to my laptop, following these instructions.-I'm also able to sync the repositories (laptop and ssh) when I commit new files in the ssh repo.--However, every time I try to get files from the ssh repo (using 'git annex get some_file'), nothing happens.-Do you know what can be happening?--Thanks!-"""]]
− doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._c 
@@ -1,15 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"- nickname="Fernando Seabra"- subject="comment 3"- date="2012-05-27T21:13:50Z"- content="""-Thanks for the quick replay!--I already did 'git annex sync', but it didn't work. The steps were: 'git clone ssh...', then 'cd annex', then 'git annex init \"laptop\"'--After that, I did a 'git annex sync', and tried to get the file, but nothing happens. That's why I found it weird.-Any other thing that might have happened?--Thanks again!-"""]]
− doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._c 
@@ -1,8 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.81.112"- subject="comment 4"- date="2012-05-27T21:33:11Z"- content="""-Try running `git annex whereis` on the file and see where it says it is.-"""]]
− doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._c 
@@ -1,18 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"- nickname="Fernando Seabra"- subject="comment 5"- date="2012-05-27T21:42:56Z"- content="""-Hi,--I guess the problem is with git-annex-shell. I tried to do 'git annex get file --from name_ssh_repo', and I got the following:--bash: git-annex-shell: command not found; failed; exit code 127--The same thing happens if I try to do 'git annex whereis'--git-annex-shell is indeed installed. How can I make my shell recognize this command?--Thanks a lot!-"""]]
− doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._c 
@@ -1,12 +0,0 @@-[[!comment format=mdwn- username="http://joeyh.name/"- ip="4.153.81.112"- subject="comment 6"- date="2012-05-27T22:08:50Z"- content="""-git-annex-shell needs to be installed in the `PATH` on any host that will hold annexed files. --If you installed with cabal, it might be `.cabal/bin/`. Whereever it was installed to is apparently not on the PATH that is set when you ssh into that host. ---"""]]
− doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._c 
@@ -1,16 +0,0 @@-[[!comment format=mdwn- username="https://www.google.com/accounts/o8/id?id=AItOawkaT0B6s9jQuMzQUYRVBgWqtO7BhT_ZSaE"- nickname="Fernando Seabra"- subject="comment 7"- date="2012-05-27T23:35:17Z"- content="""-Hi,--It was already installed in PATH. In fact, I can call it from the command line, and it is recognized (e.g. calling 'git-annex-shell' gives me 'git-annex-shell: bad parameters'). However, every time I do a 'git annex whereis' or 'git annex get file --from repo', it gives me the following error:--bash: git-annex-shell: command not found-Command ssh [\"-S\",\"/Users/username/annex/.git/annex/ssh/username@example.edu\",\"-o\",\"ControlMaster=auto\",\"-o\",\"ControlPersist=yes\",\"username@example.edu\",\"git-annex-shell 'configlist' '/~/annex'\"] failed; exit code 127--I tried to run this ssh command, but it gives me the same 'command not found' error. It seems that the problem is with the ssh repo?-The ssh repo has a git-annex-shell working and installed in PATH.-"""]]
git-annex.cabal view
@@ -1,5 +1,5 @@ Name: git-annex-Version: 3.20120614+Version: 3.20120615 Cabal-Version: >= 1.8 License: GPL Maintainer: Joey Hess <joey@kitenet.net>
make-sdist.sh view
@@ -1,4 +1,7 @@ #!/bin/bash+#+# Workaround for `cabal sdist` requiring all included files to be listed+# in .cabal.  # Create target directory sdist_dir=git-annex-$(grep '^Version:' git-annex.cabal | sed -re 's/Version: *//')@@ -6,8 +9,13 @@  find . \( -name .git -or -name dist -or -name cabal-dev \) -prune \ 	-or -not -name \\*.orig -not -type d -print \-| perl -ne 'print unless length >= 100' \+| perl -ne "print unless length >= 100 - length q{$sdist_dir}" \ | xargs cp --parents --target-directory dist/$sdist_dir  cd dist tar -caf $sdist_dir.tar.gz $sdist_dir++# Check that tarball can be unpacked by cabal.+# It's picky about tar longlinks etc.+rm -rf $sdist_dir+cabal unpack $sdist_dir.tar.gz