packages feed

git-annex 3.20120611 → 3.20120614

raw patch · 506 files changed

+4760/−3701 lines, 506 filessetup-changedbinary-added

This diff is very large; some files are shown as “too large to diff”. Download the raw patch for the complete diff.

Files

.gitignore view
@@ -13,3 +13,7 @@ Utility/Touch.hs Utility/libdiskfree.o dist+# Sandboxed builds+cabal-dev+# Project-local emacs configuration+.dir-locals.el
CHANGELOG view
@@ -1,3 +1,12 @@+git-annex (3.20120614) unstable; urgency=medium++  * addurl: Was broken by a typo introduced 2 released ago, now fixed.+    Closes: #677576+  * Install man page when run by cabal, in a location where man will+    find it, even when installing under $HOME. Thanks, Nathan Collins++ -- Joey Hess <joeyh@debian.org>  Thu, 14 Jun 2012 20:21:29 -0400+ git-annex (3.20120611) unstable; urgency=medium    * add: Prevent (most) modifications from being made to a file while it
+ CONTRIBUTING view
@@ -0,0 +1,7 @@+## Style++This project uses tabs for indentation and the code looks fine with+any tab width. If you are using Emacs, and have it configured to use+spaces for indentation, then you can add a `./.dir-locals.el` to use+tabs for files in this project. See+<http://www.emacswiki.org/emacs/DirectoryVariables>.
@@ -0,0 +1,15 @@+Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/+Source: native package++Files: *+Copyright: © 2010-2012 Joey Hess <joey@kitenet.net>+License: GPL-3++ The full text of version 3 of the GPL is distributed as doc/GPL in+ this package's source, or in /usr/share/common-licenses/GPL-3 on+ Debian systems.++Files: doc/logo.png doc/logo_small.png doc/favicon.png+Copyright: 2007 Henrik Nyh <http://henrik.nyh.se/>+           2010 Joey Hess <joey@kitenet.net>+License: other+  Free to modify and redistribute with due credit, and obviously free to use.
Command/AddUrl.hs view
@@ -73,7 +73,7 @@ 	liftIO $ createDirectoryIfMissing True (parentDir tmp) 	stopUnless (downloadUrl [url] tmp) $ do 		backend <- chooseBackend file-		let source = KeySource { keyFilename = file, contentLocation = file}+		let source = KeySource { keyFilename = file, contentLocation = tmp } 		k <- genKey source backend 		case k of 			Nothing -> stop
Makefile view
@@ -47,18 +47,22 @@ git-union-merge.1: doc/git-union-merge.mdwn 	./mdwn2man git-union-merge 1 doc/git-union-merge.mdwn > git-union-merge.1 -install: all-	install -d $(DESTDIR)$(PREFIX)/bin-	install $(bins) $(DESTDIR)$(PREFIX)/bin-	ln -sf git-annex $(DESTDIR)$(PREFIX)/bin/git-annex-shell+install-mans: $(mans) 	install -d $(DESTDIR)$(PREFIX)/share/man/man1 	install -m 0644 $(mans) $(DESTDIR)$(PREFIX)/share/man/man1++install-docs: docs install-mans 	install -d $(DESTDIR)$(PREFIX)/share/doc/git-annex 	if [ -d html ]; then \ 		rsync -a --delete html/ $(DESTDIR)$(PREFIX)/share/doc/git-annex/html/; \ 	fi -test:+install: all install-docs+	install -d $(DESTDIR)$(PREFIX)/bin+	install $(bins) $(DESTDIR)$(PREFIX)/bin+	ln -sf git-annex $(DESTDIR)$(PREFIX)/bin/git-annex-shell++test: $(sources) $(clibs) 	@if ! $(GHCMAKE) -O0 test $(clibs); then \ 		echo "** failed to build the test suite" >&2; \ 		exit 1; \@@ -96,13 +100,10 @@ 	rm -rf tmp $(bins) $(mans) test configure  *.tix .hpc $(sources) \ 		doc/.ikiwiki html dist $(clibs) -# Workaround for cabal sdist not running Setup hooks, so I cannot-# generate a file list there.-sdist: clean-	@if [ ! -e git-annex.cabal.orig ]; then cp git-annex.cabal git-annex.cabal.orig; fi-	@sed -e "s!\(Extra-Source-Files: \).*!\1$(shell find . -name .git -prune -or -not -name \\*.orig -not -type d -print | perl -ne 'print unless length >= 100')!i" < git-annex.cabal.orig > git-annex.cabal-	@cabal sdist-	@mv git-annex.cabal.orig git-annex.cabal+# Workaround for `cabal sdist` requiring all included files to be listed+# in .cabal.+sdist: clean $(mans)+	./make-sdist.sh  # Upload to hackage. hackage: sdist
Setup.hs view
@@ -1,27 +1,49 @@+{-# LANGUAGE NamedFieldPuns #-}+ {- cabal setup file -}  import Distribution.Simple import Distribution.Simple.LocalBuildInfo import Distribution.Simple.Setup-import System.Cmd+import Distribution.Simple.Utils (installOrdinaryFiles, rawSystemExit)+import Distribution.PackageDescription (PackageDescription(..))+import Distribution.Verbosity (Verbosity) import System.FilePath  import qualified Build.Configure as Configure  main = defaultMainWithHooks simpleUserHooks 	{ preConf = configure-	, instHook = install+	, postInst = myPostInst 	}  configure _ _ = do 	Configure.run Configure.tests 	return (Nothing, []) -install pkg_descr lbi userhooks flags = do-	r <- (instHook simpleUserHooks) pkg_descr lbi userhooks flags-	_ <- rawSystem "ln" ["-sf", "git-annex", -		bindir installDirs </> "git-annex-shell"]-	return r+myPostInst :: Args -> InstallFlags -> PackageDescription -> LocalBuildInfo -> IO ()+myPostInst _ (InstallFlags { installVerbosity }) pkg lbi = do+	installGitAnnexShell dest verbosity pkg lbi+	installManpages      dest verbosity pkg lbi 	where-		installDirs = absoluteInstallDirs pkg_descr lbi $-			fromFlag (copyDest defaultCopyFlags)+		dest      = NoCopyDest+		verbosity = fromFlag installVerbosity++installGitAnnexShell :: CopyDest -> Verbosity -> PackageDescription -> LocalBuildInfo -> IO ()+installGitAnnexShell copyDest verbosity pkg lbi =+	rawSystemExit verbosity "ln"+		["-sf", "git-annex", dstBinDir </> "git-annex-shell"]+	where+		dstBinDir = bindir $ absoluteInstallDirs pkg lbi copyDest++-- See http://www.haskell.org/haskellwiki/Cabal/Developer-FAQ#Installing_manpages.+--+-- Based on pandoc's Setup.hs.+installManpages :: CopyDest -> Verbosity -> PackageDescription -> LocalBuildInfo -> IO ()+installManpages copyDest verbosity pkg lbi =+	installOrdinaryFiles verbosity dstManDir srcManpages+	where+		dstManDir   = mandir (absoluteInstallDirs pkg lbi copyDest) </> "man1"+		srcManpages = zip (repeat srcManDir) manpages+		srcManDir   = ""+		manpages    = ["git-annex.1", "git-annex-shell.1"]
debian/changelog view
@@ -1,3 +1,12 @@+git-annex (3.20120614) unstable; urgency=medium++  * addurl: Was broken by a typo introduced 2 released ago, now fixed.+    Closes: #677576+  * Install man page when run by cabal, in a location where man will+    find it, even when installing under $HOME. Thanks, Nathan Collins++ -- Joey Hess <joeyh@debian.org>  Thu, 14 Jun 2012 20:21:29 -0400+ git-annex (3.20120611) unstable; urgency=medium    * add: Prevent (most) modifications from being made to a file while it
+ doc/bugs/Cabal_dependency_monadIO_missing/comment_1_14be660aa57fadec0d81b32a8b5 view
@@ -0,0 +1,75 @@+[[!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_1_14be660aa57fadec0d81b32a8b52c66f._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/Cabal_dependency_monadIO_missing/comment_2_4f4d8e1e00a2a4f7e8a8ab082e16adac._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_74de3091e8bfd7acd6795e61f39f07c6._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/Displayed_copy_speed_is_wrong/comment_2_8b240de1d5ae9229fa2d77d1cc15a552._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-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 view
@@ -0,0 +1,46 @@+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/Error_while_adding_a_file___34__createSymbolicLink:_already_exists__34__.mdwn 
@@ -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 view
@@ -0,0 +1,47 @@+[[!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_1_5a3da5f79c8563c7a450aa29728abe7c._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_416f12dbd0c2b841fac8164645b81df5._comment 
@@ -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 view
@@ -0,0 +1,25 @@+[[!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_3_c38b6f4abc9b9ad413c3b83ca04386c3._comment 
@@ -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 view
@@ -0,0 +1,30 @@+[[!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_4_cc13873175edf191047282700315beee._comment 
@@ -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 view
@@ -0,0 +1,59 @@+[[!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_5_0a1c52e2c96d19b9c3eb7e99b8c2434f._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_6_24119fc5d5963ce9dd669f7dcf006859._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_7_96fd4725df4b54e670077a18d3ac4943._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/Makefile_is_missing_dependancies/comment_8_a3555e3286cdc2bfeb9cde0ff727ba74._comment 
@@ -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._ view
@@ -0,0 +1,8 @@+[[!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/Prevent_accidental_merges/comment_1_4c46a193915eab8f308a04175cb2e40a._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 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 view
@@ -0,0 +1,8 @@+[[!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_10_94e4ac430140042a2d0fb5a16d86b4e5._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_11_56f1143fa191361d63b441741699e17f._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_12_ec5131624d0d2285d3b6880e47033f97._comment 
@@ -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 view
@@ -0,0 +1,16 @@+[[!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_13_88ed095a448096bf8a69015a04e64df1._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_14_89a960b6706ed703b390a81a8bc4e311._comment 
@@ -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 view
@@ -0,0 +1,71 @@+[[!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_15_6b8867b8e48bf807c955779c9f8f0909._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_16_5c2dd6002aadaab30841b77a5f5aed34._comment 
@@ -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 view
@@ -0,0 +1,43 @@+[[!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_17_62fccb04b0e4b695312f7a3f32fb96ee._comment 
@@ -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 view
@@ -0,0 +1,24 @@+[[!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_18_64fab50d95de619eb2e8f08f90237de1._comment 
@@ -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 view
@@ -0,0 +1,11 @@+[[!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_19_4253988ed178054c8b6400beeed68a29._comment 
@@ -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 view
@@ -0,0 +1,17 @@+[[!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_1_34120e82331ace01a6a4960862d38f2d._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_20_7db27d1a22666c831848bc6c06d66a84._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_cc53d1681d576186dbc868dd9801d551._comment 
@@ -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 view
@@ -0,0 +1,57 @@+[[!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_3_68f0f8ae953589ae26d57310b40c878d._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_4_c52be386f79f14c8570a8f1397c68581._comment 
@@ -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 view
@@ -0,0 +1,107 @@+[[!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_5_7f1330a1e541b0f3e2192e596d7f7bee._comment 
@@ -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 view
@@ -0,0 +1,9 @@+[[!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_6_0c46f5165ceb5a7b9ea9689c33b3a4f8._comment 
@@ -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 view
@@ -0,0 +1,22 @@+[[!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_7_237a137cce58a28abcc736cbf2c420b0._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_8_efafa203addf8fa79e33e21a87fb5a2b._comment 
@@ -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 view
@@ -0,0 +1,66 @@+[[!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/Problems_running_make_on_osx/comment_9_cc283b485b3c95ba7eebc8f0c96969b3._comment 
@@ -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 view
@@ -0,0 +1,15 @@+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/__39__annex_add__39___fails_to___39__git_add__39___for_parent_relative_path.mdwn 
@@ -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 view
@@ -0,0 +1,24 @@+[[!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/conflicting_haskell_packages/comment_1_e552a6cc6d7d1882e14130edfc2d6b3b._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_1_f33b83025ce974e496f83f248275a66a._comment 
@@ -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 view
@@ -0,0 +1,9 @@+[[!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_2_195106ca8dedad5f4d755f625e38e8af._comment 
@@ -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 view
@@ -0,0 +1,15 @@+[[!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/conq:_invalid_command_syntax/comment_3_55af43e2f43a4c373f7a0a33678d0b1c._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_1_7c12499c9ac28a9883c029f8c659eb57._comment 
@@ -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 view
@@ -0,0 +1,15 @@+[[!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_2_f85d8023cdbc203bb439644cf7245d4e._comment 
@@ -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 view
@@ -0,0 +1,11 @@+[[!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/copy_doesn__39__t_scale/comment_3_4592765c3d77bb5664b8d16867e9d79c._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_09d8e4e66d8273fab611bd29e82dc7fc._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 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 view
@@ -0,0 +1,8 @@+[[!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/fails_to_handle_lot_of_files/comment_2_fd2ec05f4b5a7a6ae6bd9f5dbc3156de._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-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 view
@@ -0,0 +1,10 @@+[[!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_1_a868e805be43c5a7c19c41f1af8e41e6._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_8a65f6d3dcf5baa3f7f2dbe1346e2615._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/free_space_checking/comment_3_0fc6ff79a357b1619d13018ccacc7c10._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 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 view
@@ -0,0 +1,8 @@+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__47__fix_should_check__47__fix_the_permissions_of_.git__47__annex.mdwn 
@@ -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 view
@@ -0,0 +1,57 @@+    (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/fsck_claims_failed_checksum_when_less_copies_than_required_are_found.mdwn 
@@ -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_ view
@@ -0,0 +1,15 @@+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_command_line_constructed_by_unannex_command_has_tons_of_redundant_-a_paramters.mdwn 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_10_5ec2f965c80cc5dd31ee3c4edb695664._comment 
@@ -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 view
@@ -0,0 +1,26 @@+[[!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_1_0531dcfa833b0321a7009526efe3df33._comment 
@@ -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 view
@@ -0,0 +1,27 @@+[[!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_2_7101d07400ad5935f880dc00d89bf90e._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_3_57010bcaca42089b451ad8659a1e018e._comment 
@@ -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 view
@@ -0,0 +1,34 @@+[[!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_4_79d96599f757757f34d7b784e6c0e81c._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_5_d61f5693d947b9736b29fca1dbc7ad76._comment 
@@ -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 view
@@ -0,0 +1,19 @@+[[!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_6_f63de6fe2f7189c8c2908cc41c4bc963._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_7_7f20d0b2f6ed1c34021a135438037306._comment 
@@ -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 view
@@ -0,0 +1,21 @@+[[!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_8_6a00500b24ba53248c78e1ffc8d1a591._comment 
@@ -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 view
@@ -0,0 +1,9 @@+[[!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/git_rename_detection_on_file_move/comment_9_75e0973f6d573df615e01005ebcea87d._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_5f60006c9bb095167d817f234a14d20b._comment 
@@ -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 view
@@ -0,0 +1,23 @@+[[!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_2_cd0123392b16d89db41b45464165c247._comment 
@@ -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 view
@@ -0,0 +1,16 @@+[[!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_3_86d9e7244ae492bcbe62720b8c4fc4a9._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_4_91439d4dbbf1461e281b276eb0003691._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_5_ca33a9ca0df33f7c1b58353d7ffb943d._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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/problem_with_upgrade_v2_-__62___v3/comment_6_f360f0006bc9115bc5a3e2eb9fe58abd._comment 
@@ -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 view
@@ -0,0 +1,17 @@+[[!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_1_3c7e3f021c2c94277eecf9c8af6cec5f._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_2_bad4c4c5f54358d1bc0ab2adc713782a._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_3_4f936a5d3f9c7df64c8a87e62b7fbfdc._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_4_93bee35f5fa7744834994bc7a253a6f9._comment 
@@ -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 view
@@ -0,0 +1,11 @@+[[!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_5_519cda534c7aea7f5ad5acd3f76e21fa._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_6_52e0bfff2b177b6f92e226b25d2f3ff1._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_7_0cc588f787d6eecfa19a8f6cee4b07b5._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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/problems_with_utf8_names/comment_8_ff5c6da9eadfee20c18c86b648a62c47._comment 
@@ -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 view
@@ -0,0 +1,20 @@+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/support_bare_git_repo__44___with_the_annex_directory_exposed_to_http.mdwn 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/uninit_does_not_work_in_old_repos/comment_1_bc0619c6e17139df74639448aa6a0f72._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 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 view
@@ -0,0 +1,5 @@+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/bugs/wishlist:_allow_users_to_provide_UUID_when_running___96__git_annex_init__96__.mdwn 
@@ -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/contributing.mdwn view
@@ -0,0 +1,7 @@+## Style++This project uses tabs for indentation and the code looks fine with+any tab width. If you are using Emacs, and have it configured to use+spaces for indentation, then you can add a `./.dir-locals.el` to use+tabs for files in this project. See+<http://www.emacswiki.org/emacs/DirectoryVariables>.
doc/design/assistant/android.mdwn view
@@ -14,6 +14,18 @@ * git (not all git commands are needed,   but core plumbing and a few like `git-add` are.) +## GHC Android?++Android's native SDK does not use glibc. GHC's runtime links with glibc.+This could be an enormous problem. Other people want to see GHC able to+target Android, of course, so someone may solve it before I get stuck on+it.++References:++* <http://stackoverflow.com/questions/5151858/running-a-haskell-program-on-the-android-os>+* <http://www.reddit.com/r/haskell/comments/ful84/haskell_on_android/>+ ### Android specific features  The app should be aware of power status, and avoid expensive background@@ -56,8 +68,6 @@ version git-annex dependend upon existing on the phone. (Maybe the phone would have to be always considered an untrusted repo, which probably makes sense anyway.)--Problem:   #### crazy `LD_PRELOAD` wrapper
+ doc/design/assistant/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._commen view
@@ -0,0 +1,8 @@+[[!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/android/comment_1_8be9a74e5fc4641c2bf2e1bb7673dd59._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_d6015338f602b574a3805de5481fc45e._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_4d6b23fc6442e0ee0303523cb69d0fba._comment 
@@ -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 view
@@ -0,0 +1,14 @@+[[!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_3_03f5b2344c2a47dea60086f217d60f9b._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_3__more_races/comment_4_860e90e989ec022100001c65e353a91e._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_bf3c9c33cc0dea5eaeb6f2af110b924b._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/blog/day_4__speed/comment_2_33aba4c9abaa3e6a05a2c87ab7df9d0e._comment 
@@ -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/blog/day_6__polish.mdwn view
@@ -1,12 +1,13 @@-Last night, I polished the `git annex watch` command.+Since my last blog, I've been polishing the `git annex watch` command.  First, I fixed the double commits problem. There's still some extra committing going on in the `git-annex` branch that I don't understand. It-seems like a monad shutdown event is somehow being triggered whenever+seems like a shutdown event is somehow being triggered whenever a git command is run by the commit thread. -I also made `git annex watch` run as a proper daemon,-and `git annex watch --stop` stop it.+I also made `git annex watch` run as a proper daemon, with locking to+prevent multiple copies running, and a pid file, and everything.+I made `git annex watch --stop` stop it.  --- @@ -32,3 +33,18 @@ Then I started running `git annex watch` on my own real git annex repos, and noticed some problems.. Like it turns normal files already checked into git into symlinks. And it leaks memory scanning a big tree. Oops..++---++I put together a quick screencast demoing `git annex watch`.++<video controls src="http://joeyh.name/screencasts/git-annex-watch.ogg"></video>++While making the screencast, I noticed that `git-annex watch` was spinning+in strace, which is bad news for powertop and battery usage. This seems to+be a [GHC bug](http://bugs.debian.org/677096) also affecting Xmonad. I+tried switching to GHC's threaded runtime, which solves that problem, but+causes git-annex to hang under heavy load. Tried to debug that for quite a+while, but didn't get far. Will need to investigate this further.. +Am seeing indications that this problem only affects ghc 7.4.1; in+particular 7.4.2 does not seem to have the problem.
+ doc/design/assistant/blog/day_7__bugfixes.mdwn view
@@ -0,0 +1,45 @@+Kickstarter is over. Yay!++Today I worked on the bug where `git annex watch` turned regular files+that were already checked into git into symlinks. So I made it check+if a file is already in git before trying to add it to the annex.++The tricky part was doing this check quickly. Unless I want to write my+own git index parser (or use one from Hackage), this check requires running+`git ls-files`, once per file to be added. That won't fly if a huge+tree of files is being moved or unpacked into the watched directory.++Instead, I made it only do the check during `git annex watch`'s initial+scan of the tree. This should be ok, because once it's running, you+won't be adding new  files to git anyway, since it'll automatically annex+new files. This is good enough for now, but there are at least two problems+with it:++* Someone might `git merge` in a branch that has some regular files,+  and it would add the merged in files to the annex.+* Once `git annex watch` is running, if you modify a file that was+  checked into git as a regular file, the new version will be added+  to the annex.++I'll probably come back to this issue, and may well find myself directly+querying git's index.++---++I've started work to fix the memory leak I see when running `git annex+watch` in a large repository (40 thousand files). As always with a Haskell+memory leak, I crack open [Real World Haskell's chapter on profiling](http://book.realworldhaskell.org/read/profiling-and-optimization.html).++Eventually this yields a nice graph of the problem:++[[!img profile.png alt="memory profile"]]++So, looks like a few minor memory leaks, and one huge leak. Stared+at this for a while and trying a few things, and got a much better result:++[[!img profile2.png alt="memory profile"]]++I may come back later and try to improve this further, but it's not bad memory+usage. But, it's still rather slow to start up in such a large repository,+and its initial scan is still doing too much work. I need to optimize+more..
+ doc/design/assistant/blog/day_7__bugfixes/profile.png view

binary file changed (absent → 47098 bytes)

+ doc/design/assistant/blog/day_7__bugfixes/profile2.png view

binary file changed (absent → 230937 bytes)

+ doc/design/assistant/blog/day_8__speed.mdwn view
@@ -0,0 +1,67 @@+Since last post, I've worked on speeding up `git annex watch`'s startup time+in a large repository.++The problem was that its initial scan was naively staging every symlink in+the repository, even though most of them are, presumably, staged correctly+already. This was done in case the user copied or moved some symlinks+around while `git annex watch` was not running -- we want to notice and+commit such changes at startup.++Since I already had the `stat` info for the symlink, it can look at the+`ctime` to see if the symlink was made recently, and only stage it if so.+This sped up startup in my big repo from longer than I cared to wait (10++minutes, or half an hour while profiling) to a minute or so. Of course,+inotify events are already serviced during startup, so making it scan+quickly is really only important so people don't think it's a resource hog.+First impressions are important. :)++But what does "made recently" mean exactly? Well, my answer is possibly+overengineered, but most of it is really groundwork for things I'll need+later anyway. I added a new data structure for tracking the status of the+daemon, which is periodically written to disk by another thread (thread #6!)+to `.git/annex/daemon.status` Currently it looks like this; I anticipate+adding lots more info as I move into the [[syncing]] stage:++	lastRunning:1339610482.47928s+	scanComplete:True++So, only symlinks made after the daemon was last running need to be+expensively staged on startup. Although, as RichiH pointed out,+this fails if the clock is changed. But I have been planning to have a+cleanup thread anyway, that will handle this, and other+potential problems, so I think that's ok.++Stracing its startup scan, it's fairly tight now. There are some repeated +`getcwd` syscalls that could be optimised out for a minor speedup.++----++Added the sanity check thread. Thread #7! It currently only does one sanity+check per day, but the sanity check is a fairly lightweight job,+so I may make it run more frequently. OTOH, it may never ever find a+problem, so once per day seems a good compromise. ++Currently it's only checking that all files in the tree are properly staged+in git. I might make it `git annex fsck` later, but fscking the whole tree+once per day is a bit much. Perhaps it should only fsck a few files per+day? TBD++Currently any problems found in the sanity check are just fixed and logged.+It would be good to do something about getting problems that might indicate+bugs fed back to me, in a privacy-respecting way. TBD++----++I also refactored the code, which was getting far too large to all be in+one module. ++I have been thinking about renaming `git annex watch` to `git annex assistant`,+but I think I'll leave the command name as-is. Some users might+want a simple watcher and stager, without the assistant's other features+like syncing and the webapp. So the next stage of the+[[roadmap|design/assistant]] will be a different command that also runs+`watch`.++At this point, I feel I'm done with the first phase of [[inotify]].+It has a couple known bugs, but it's ready for brave beta testers to try.+I trust it enough to be running it on my live data.
+ doc/design/assistant/blog/day_9__correctness.mdwn view
@@ -0,0 +1,30 @@+	git merge watch_++My cursor has been mentally poised here all day, but I've been reluctant to+merge watch into master. It seems solid, but is it correct? I was able to+think up a lot of races it'd be subject to, and deal with them, but did I+find them all?++Perhaps I need to do some automated fuzz testing to reassure myself.+I looked into using [genbackupdata](http://liw.fi/genbackupdata/) to that+end. It's not quite what I need, but could be+[moved in that direction](http://bugs.debian.org/677542). Or I could write+my own fuzz tester, but it seems better to use someone else's, because +a) laziness and b) they're less likely to have the same blind spots I do.++My reluctance to merge isn't helped by the known bugs with files that are+either already open before `git annex watch` starts, or are opened by two+processes at once, and confuse it into annexing the still-open file when one+process closes it.++I've been thinking about just running `lsof` on every file as it's being+annexed to check for that, but in the end, `lsof` is too slow. Since its+check involves trawling through all of /proc, it takes it a good half a+second to check a file, and adding 25 seconds to the time it takes to+process 100 files is just not acceptable.++But an option that could work is to run `lsof` after a bunch of new files+have been annexed. It can check a lot of files nearly as fast as a single+one. In the rare case that an annexed file is indeed still open, it could+be moved back out of the annex. Then when its remaining writer finally+closes it, another inotify event would re-annex it.
doc/design/assistant/inotify.mdwn view
@@ -1,44 +1,56 @@ Finish "git annex watch" command, which runs, in the background, watching via inotify for changes, and automatically annexing new files, etc. -There is a `watch` branch in git that adds such a command. To make this-really useful, it needs to:+There is a `watch` branch in git that adds the command. -- on startup, add any files that have appeared since last run **done**-- on startup, fix the symlinks for any renamed links **done**-- on startup, stage any files that have been deleted since last run-  (seems to require a `git commit -a` on startup, or at least a-  `git add --update`, which will notice deleted files) **done**-- notice new files, and git annex add **done**-- notice renamed files, auto-fix the symlink, and stage the new file location-  **done**-- handle cases where directories are moved outside the repo, and stop-  watching them **done**-- when a whole directory is deleted or moved, stage removal of its-  contents from the index **done**-- notice deleted files and stage the deletion-  (tricky; there's a race with add since it replaces the file with a symlink..)-  **done**-- Gracefully handle when the default limit of 8192 inotified directories-  is exceeded. This can be tuned by root, so help the user fix it.-  **done**-- periodically auto-commit staged changes (avoid autocommitting when-  lots of changes are coming in) **done**-- coleasce related add/rm events for speed and less disk IO **done**-- don't annex `.gitignore` and `.gitattributes` files **done**-- run as a daemon **done**-- tunable delays before adding new files, etc+## known bugs++* A process has a file open for write, another one closes it,+  and so it's added. Then the first process modifies it.++  Or, a process has a file open for write when `git annex watch` starts+  up, it will be added to the annex. If the process later continues+  writing, it will change content in the annex.++  This changes content in the annex, and fsck will later catch+  the inconsistency.++  Possible fixes: ++  * 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.+  * 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.+  * Tracking file opens and closes with inotify could tell if any other+    processes have the file open. But there are problems.. It doesn't+    seem to differentiate between files opened for read and for write.+    And there would still be a race after the last close and before it's+    injected into the annex, where it could be opened for write again.+    Would need to detect that and undo the annex injection or something.++* If a file is checked into git as a normal file and gets modified+  (or merged, etc), it will be converted into an annexed file.+  See [[blog/day_7__bugfixes]]++* When you `git annex unlock` a file, it will immediately be re-locked.++## todo++- Support OSes other than Linux; it only uses inotify currently.+  OSX and FreeBSD use the same mechanism, and there is a Haskell interface+  for it,+- Run niced and ioniced? Seems to make sense, this is a background job. - configurable option to only annex files meeting certian size or   filename criteria-- option to check files not meeting annex criteria into git directly+- option to check files not meeting annex criteria into git directly,+  automatically - honor .gitignore, not adding files it excludes (difficult, probably   needs my own .gitignore parser to avoid excessive running of git commands   to check for ignored files) - Possibly, when a directory is moved out of the annex location,-  unannex its contents.-- Support OSes other than Linux; it only uses inotify currently.-  OSX and FreeBSD use the same mechanism, and there is a Haskell interface-  for it,+  unannex its contents. (Does inotify tell us where the directory moved+  to so we can access it?)  ## the races @@ -61,25 +73,6 @@   Fixed this problem; Now it hard links the file to a temp directory and   operates on the hard link, which is also made unwritable. -* A process has a file open for write, another one closes it, and so it's-  added. Then the first process modifies it.--  **Currently unfixed**; This changes content in the annex, and fsck will-  later catch the inconsistency.--  Possible fixes: --  * Somehow track or detect if a file is open for write by any processes.-  * 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.-  * Tracking file opens and closes with inotify could tell if any other-    processes have the file open. But there are problems.. It doesn't-    seem to differentiate between files opened for read and for write.-    And there would still be a race after the last close and before it's-    injected into the annex, where it could be opened for write again.-    Would need to detect that and undo the annex injection or something.- * File is added and then replaced with another file before the annex add   makes its symlink. @@ -108,3 +101,29 @@    Not a problem; The removal event removes the old file from the index, and   the add event adds the new one.++## done++- on startup, add any files that have appeared since last run **done**+- on startup, fix the symlinks for any renamed links **done**+- on startup, stage any files that have been deleted since last run+  (seems to require a `git commit -a` on startup, or at least a+  `git add --update`, which will notice deleted files) **done**+- notice new files, and git annex add **done**+- notice renamed files, auto-fix the symlink, and stage the new file location+  **done**+- handle cases where directories are moved outside the repo, and stop+  watching them **done**+- when a whole directory is deleted or moved, stage removal of its+  contents from the index **done**+- notice deleted files and stage the deletion+  (tricky; there's a race with add since it replaces the file with a symlink..)+  **done**+- Gracefully handle when the default limit of 8192 inotified directories+  is exceeded. This can be tuned by root, so help the user fix it.+  **done**+- periodically auto-commit staged changes (avoid autocommitting when+  lots of changes are coming in) **done**+- coleasce related add/rm events for speed and less disk IO **done**+- don't annex `.gitignore` and `.gitattributes` files **done**+- run as a daemon **done**
+ doc/design/assistant/inotify/comment_1_3d3ff74447452d65c10ccc3dbfc323cd._commen view
@@ -0,0 +1,7 @@+[[!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_1_3d3ff74447452d65c10ccc3dbfc323cd._comment 
@@ -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 view
@@ -0,0 +1,7 @@+[[!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/inotify/comment_2_a3c0fa6d97397c508b4b8aafdcee8f6f._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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._ view
@@ -0,0 +1,31 @@+[[!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/A_really_stupid_question/comment_1_40e02556de0b00b94f245a0196b5a89f._comment 
@@ -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/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comme view
@@ -0,0 +1,7 @@+[[!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/Debugging_Git_Annex/comment_1_ce63b2ee641a2338f1ad5ded9e6f09a8._comment 
@@ -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 view
@@ -0,0 +1,1 @@+Moved to [[bugs|bugs/Error_while_adding_a_file___34__createSymbolicLink:_already_exists__34__]] --[[Joey]]
− doc/forum/Error_while_adding_a_file___34__createSymbolicLink:_already_exists__34__.mdwn 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_1_f50883133d5d4903cc95c0dcaa52d052._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_e90aa3259d9a12cd67daa27d42d69ab5._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/Getting_started_with_Amazon_S3/comment_3_c3adce7c0f29e71ed9dd07103ede2c1a._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_a870ec991078c95a6bb683d6962ab56e._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_71419376ef50a679ea8f0f9e16991c17._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_3_fea43664a500111ca99f4043e0dadb14._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_4_56fb2dab1d4030c9820be32b495afdf0._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_5_a6ec9c5a4a3c0bac1df87f1df9be140b._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/Git_Annex_Transfer_Protocols/comment_6_1678452fb7114aeabcf0cc3d5f6c69b0._comment 
@@ -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/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85d view
@@ -0,0 +1,12 @@+[[!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/Making_git-annex_less_necessary/comment_1_03faaa3866778d24cd03887b85dc9954._comment 
@@ -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/Podcast_syncing_use-case/comment_1_ace6f9d3a950348a3ac0ff592b62e786._ view
@@ -0,0 +1,10 @@+[[!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_1_ace6f9d3a950348a3ac0ff592b62e786._comment 
@@ -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._ view
@@ -0,0 +1,8 @@+[[!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/Podcast_syncing_use-case/comment_2_930a6620b4d516e69ed952f9da5371bb._comment 
@@ -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 view
@@ -0,0 +1,77 @@+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/Preserving_file_access_rights_in_directory_tree_below_objects__47__.mdwn 
@@ -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 view
@@ -0,0 +1,15 @@+[[!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/Recommended_number_of_repositories/comment_1_3ef256230756be8a9679b107cdbfd018._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_1_2b60e13e5f7b8cee56cf2ddc6c47f64d._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_24ff2c1eb643077daa37c01644cebcd2._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/Sharing_annex_with_local_clones/comment_3_5359b8eada24d27be83214ac0ae62f23._comment 
@@ -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/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943b view
@@ -0,0 +1,8 @@+[[!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/advantages_of_SHA__42___over_WORM/comment_1_96c354cac4b5ce5cf6664943bc84db1d._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_1_aa05008dfe800474ff76678a400099e1._comment 
@@ -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 view
@@ -0,0 +1,19 @@+[[!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_2_008554306dd082d7f543baf283510e92._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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/can_git-annex_replace_ddm__63__/comment_3_4c69097fe2ee81359655e59a03a9bb8d._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_1_a38ded23b7f288292a843abcb1a56f38._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_cd1c98b1276444e859a22c3dbd6f2a79._comment 
@@ -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 view
@@ -0,0 +1,24 @@+[[!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_3_18531754089c991b6caefc57a5c17fe9._comment 
@@ -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 view
@@ -0,0 +1,11 @@+[[!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_4_3b89b6d1518267fcbc050c9de038b9ca._comment 
@@ -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 view
@@ -0,0 +1,16 @@+[[!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_5_27801584325d259fa490f67273f2ff71._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_6_496b0d9b86869bbac3a1356d53a3dda4._comment 
@@ -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 view
@@ -0,0 +1,27 @@+[[!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/confusion_with_remotes__44___map/comment_7_9a456f61f956a3d5e81e723d5a90794c._comment 
@@ -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 view
@@ -0,0 +1,15 @@+[[!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_1_b91070218b9d5fb687eeee1f244237ad._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_2_f51c53f3f6e6ee1ad463992657db5828._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_3_692d6d4cd2f75a497e7d314041a768d2._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_4_7ceb395bf8a2e6a041ccd8de63b1b6eb._comment 
@@ -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 view
@@ -0,0 +1,13 @@+[[!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/fsck_gives_false_positives/comment_5_86484a504c3bbcecd5876982b9c95688._comment 
@@ -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 view
@@ -0,0 +1,17 @@+[[!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_1_198325d2e9337c90f026396de89eec0e._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_c7aeefa6ef9a2e75d8667b479ade1b7f._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_3_1ff08a3e0e63fa0e560cbc9602245caa._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 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 view
@@ -0,0 +1,8 @@+[[!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_4_1ba6ddf54843c17c7d19a9996f2ab712._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_5_404b723a681eb93fee015cea8024b6bc._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_6_0d87d0e26461494b1d7f8a701a924729._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 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 view
@@ -0,0 +1,10 @@+[[!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-annex_communication_channels/comment_7_2c87c7a0648fe87c2bf6b4391f1cc468._comment 
@@ -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. view
@@ -0,0 +1,10 @@+[[!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_1_4f333cb71ed1ff259bbfd86704806aa6._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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_2_73d2a015b1ac79ec99e071a8b1e29034._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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_3_c533400e22c306c033fcd56e64761b0b._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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_4_75b0e072e668aa46ff0a8d62a6620306._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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_5_f5ec9649d9f1dc122e715de5533bc674._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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-subtree_support__63__/comment_6_85df530f7b6d76b74ac8017c6034f95e._comment 
@@ -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. view
@@ -0,0 +1,36 @@+[[!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_1_9c245db3518d8b889ecdf5115ad9e053._comment 
@@ -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. view
@@ -0,0 +1,14 @@+[[!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_2_0f7f4a311b0ec1d89613e80847e69b42._comment 
@@ -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. view
@@ -0,0 +1,14 @@+[[!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_3_1aa89725b5196e40a16edeeb5ccfa371._comment 
@@ -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. view
@@ -0,0 +1,37 @@+[[!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_4_646f2077edcabc000a7d9cb75a93cf55._comment 
@@ -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. view
@@ -0,0 +1,10 @@+[[!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_5_4f2a05ef6551806dd0ec65372f183ca4._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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_6_3925d1aa56bce9380f712e238d63080f._comment 
@@ -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. view
@@ -0,0 +1,8 @@+[[!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_7_24c45ee981b18bc78325c768242e635d._comment 
@@ -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. view
@@ -0,0 +1,12 @@+[[!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_pull_remote_git-annex/comment_8_7e76ee9b6520cbffaf484c9299a63ad3._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!comment format=mdwn+ username="http://joey.kitenet.net/"+ nickname="joey"+ subject="fixed that"+ date="2011-10-13T15:36:59Z"+ content="""+:)+"""]]
− doc/forum/git_tag_missing_for_3.20111011/comment_1_7a53bf273f3078ab3351369ef2b5f2a6._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_1_c55c56076be4f54251b0b7f79f28a607._comment 
@@ -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 view
@@ -0,0 +1,14 @@+[[!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_2_504c96959c779176f991f4125ea22009._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_3_9134bde0a13aac0b6a4e5ebabd7f22e8._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_4_0de9170e429cbfea66f5afa8980d45ac._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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/hashing_objects_directories/comment_5_ef6cfd49d24c180c2d0a062e5bd3a0be._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/incompatible_versions__63__/comment_1_629f28258746d413e452cbd42a1a43f4._comment 
@@ -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. view
@@ -0,0 +1,10 @@+[[!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_1_7d6319e8c94dfe998af9cfcbf170efb2._comment 
@@ -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. view
@@ -0,0 +1,15 @@+[[!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_2_e7395cb6e01f42da72adf71ea3ebcde4._comment 
@@ -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. view
@@ -0,0 +1,10 @@+[[!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/location_tracking_cleanup/comment_3_c15428cec90e969284a5e690fb4b2fde._comment 
@@ -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/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._ view
@@ -0,0 +1,11 @@+[[!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/post-copy__47__sync_hook/comment_1_c8322d4b9bbf5eac80b48c312a42fbcf._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_10_683768c9826b0bf0f267e8734b9eb872._comment 
@@ -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 view
@@ -0,0 +1,30 @@+[[!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_11_6b541ed834ef45606f3b98779a25a148._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_12_ca8ca35d6cd4a9f94568536736c12adc._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_13_00c82d320c7b4bb51078beba17e14dc8._comment 
@@ -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 view
@@ -0,0 +1,32 @@+[[!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_14_b63568b327215ef8f646a39d760fdfc0._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_15_cb7c856d8141b2de3cc95874753f1ee5._comment 
@@ -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 view
@@ -0,0 +1,32 @@+[[!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_1_a32f7efd18d174845099a4ed59e6feae._comment 
@@ -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 view
@@ -0,0 +1,15 @@+[[!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_2_66dc9b65523a9912411db03c039ba848._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_3_9b7d89da52f7ebb7801f9ec8545c3aba._comment 
@@ -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 view
@@ -0,0 +1,20 @@+[[!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_4_dc8a3f75533906ad3756fcc47f7e96bb._comment 
@@ -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 view
@@ -0,0 +1,24 @@+[[!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_5_afe5035a6b35ed2c7e193fb69cc182e2._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_6_3660d45c5656f68924acbd23790024ee._comment 
@@ -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 view
@@ -0,0 +1,15 @@+[[!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_7_33db51096f568c65b22b4be0b5538c0d._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_8_6e5b42fdb7801daadc0b3046cbc3d51e._comment 
@@ -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 view
@@ -0,0 +1,14 @@+[[!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/pure_git-annex_only_workflow/comment_9_ace319652f9c7546883b5152ddc82591._comment 
@@ -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 view
@@ -0,0 +1,36 @@+[[!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_1_8ad3cccd7f66f6423341d71241ba89fc._comment 
@@ -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 view
@@ -0,0 +1,18 @@+[[!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_2_be6acbc26008a9cb54e7b8f498f2c2a2._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/relying_on_git_for_numcopies/comment_3_43d8e1513eb9947f8a503f094c03f307._comment 
@@ -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 view
@@ -0,0 +1,11 @@+[[!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/retrieving_previous_versions/comment_1_a4e83f688d4ec9177e7bf520f12ed26d._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_1_ee21f32e90303e20339e0a568321bbbe._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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/rsync_over_ssh__63__/comment_2_aa690da6ecfb2b30fc5080ad76dc77b1._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_1_c7dc199c5740a0e7ba606dfb5e3e579a._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_2_e357db3ccc4079f07a291843975535eb._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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_3_fcfafca994194d57dccf5319c7c9e646._comment 
@@ -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 view
@@ -0,0 +1,20 @@+[[!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/sparse_git_checkouts_with_annex/comment_4_04dc14880f31eee2b6d767d4d4258c5a._comment 
@@ -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 view
@@ -0,0 +1,46 @@+[[!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_1_dcd4cd41280b41512bbdffafaf307993._comment 
@@ -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 view
@@ -0,0 +1,36 @@+[[!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_2_58a72a9fe0f58c7af0b4d7927a2dd21d._comment 
@@ -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 view
@@ -0,0 +1,16 @@+[[!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/unannex_alternatives/comment_3_b1687fc8f9e7744327bbeb6f0635d1cd._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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/unlock__47__lock_always_gets_me/comment_1_dee73a7ea3e1a5154601adb59782831f._comment 
@@ -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 view
@@ -0,0 +1,7 @@+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/using_git_annex_to_merge_and_synchronize_2_directories___40__like_unison__41__.mdwn 
@@ -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/windows_port__63__/comment_1_23fa9aa3b00940a1c1b3876c35eef019._commen view
@@ -0,0 +1,9 @@+[[!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/windows_port__63__/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/wishlist:_command_options_changes/comment_1_bfba72a696789bf21b2435dea view
@@ -0,0 +1,17 @@+[[!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_1_bfba72a696789bf21b2435dea15f967a._comment 
@@ -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 view
@@ -0,0 +1,19 @@+[[!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_2_f6a637c78c989382e3c22d41b7fb4cc2._comment 
@@ -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 view
@@ -0,0 +1,8 @@+[[!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:_command_options_changes/comment_3_bf1114533d2895804e531e76eb6b8095._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 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 view
@@ -0,0 +1,10 @@+[[!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_1_9926132ec6052760cdf28518a24e2358._comment 
@@ -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 view
@@ -0,0 +1,12 @@+[[!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_2_c43932f4194aba8fb2470b18e0817599._comment 
@@ -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 view
@@ -0,0 +1,10 @@+[[!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_3_c13f4f9c3d5884fc6255fd04feadc2b1._comment 
@@ -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 view

file too large to diff

− doc/forum/wishlist:_git-annex_replicate/comment_4_63f24abf086d644dced8b01e1a9948c9._comment

file too large to diff

+ doc/forum/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090 view

file too large to diff

− doc/forum/wishlist:_git_annex_status/comment_1_994bfd12c5d82e08040d6116915c5090._comment

file too large to diff

+ doc/forum/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824 view

file too large to diff

− doc/forum/wishlist:_git_annex_status/comment_2_c2b0ce025805b774dc77ce264a222824._comment

file too large to diff

+ doc/forum/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7 view

file too large to diff

− doc/forum/wishlist:_git_annex_status/comment_3_d1fd70c67243971c96d59e1ffb7ef6e7._comment

file too large to diff

+ doc/forum/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94 view

file too large to diff

− doc/forum/wishlist:_git_annex_status/comment_4_9aeeb83d202dc8fb33ff364b0705ad94._comment

file too large to diff

+ doc/forum/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_ view

file too large to diff

− doc/forum/wishlist:_push_to_cia.vc_from_the_website__39__s_repo__44___not_your_personal_one.mdwn

file too large to diff

+ doc/forum/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c view

file too large to diff

− doc/forum/wishlist:_simpler_gpg_usage/comment_1_6923fa6ebc0bbe7d93edb1d01d7c46c5._comment

file too large to diff

+ doc/forum/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae view

file too large to diff

− doc/forum/wishlist:_simpler_gpg_usage/comment_2_6fc874b6c391df242bd2592c4a65eae8._comment

file too large to diff

+ doc/forum/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dab view

file too large to diff

− doc/forum/wishlist:_simpler_gpg_usage/comment_3_012f340c8c572fe598fc860c1046dabd._comment

file too large to diff

+ doc/forum/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661e view

file too large to diff

− doc/forum/wishlist:_simpler_gpg_usage/comment_4_e0c2a13217b795964f3b630c001661ef._comment

file too large to diff

+ doc/forum/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068c view

file too large to diff

− doc/forum/wishlist:_simpler_gpg_usage/comment_5_9668b58eb71901e1db8da7db38e068ca._comment

file too large to diff

− doc/news/version_3.20120430.mdwn

file too large to diff

+ doc/news/version_3.20120614.mdwn view

file too large to diff

+ doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._co view

file too large to diff

− doc/tips/finding_duplicate_files/comment_1_ddb477ca242ffeb21e0df394d8fdf5d2._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_1_9a2a2a8eac9af97e0c984ad105763a73._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecef view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_2_d8efea4ab9576555fadbb47666ecefa9._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd374 view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_3_807035f38509ccb9f93f1929ecd37417._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_4_eb81f824aadc97f098379c5f7e4fba4c._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_5_f688309532d2993630e9e72e87fb9c46._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718ad view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_6_3e203e010a4df5bf03899f867718adc5._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c8734805722 view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_7_f8fd08b6ab47378ad88c87348057220d._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa9 view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa936._comment

file too large to diff

+ doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c2 view

file too large to diff

− doc/tips/using_gitolite_with_git-annex/comment_9_28418635a6ed7231b89e02211cd3c236._comment

file too large to diff

+ doc/todo/git_annex_init_:_include_repo_description_and__47__or_UUID_in_commit_m view

file too large to diff

− doc/todo/git_annex_init_:_include_repo_description_and__47__or_UUID_in_commit_message.mdwn

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_1_ba03333dc76ff49eccaba375e68cb525._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_1_ba03333dc76ff49eccaba375e68cb525._comment

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_2_81276ac309959dc741bc90101c213ab7._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_2_81276ac309959dc741bc90101c213ab7._comment

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_3_79bdf9c51dec9f52372ce95b53233bb2._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_3_79bdf9c51dec9f52372ce95b53233bb2._comment

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_4_93aada9b1680fed56cc6f0f7c3aca5e5._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_4_93aada9b1680fed56cc6f0f7c3aca5e5._comment

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_5_821c382987f105da72a50e0a5ce61fdc._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_5_821c382987f105da72a50e0a5ce61fdc._comment

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_6_8834c3a3f1258c4349d23aff8549bf35._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_6_8834c3a3f1258c4349d23aff8549bf35._comment

file too large to diff

+ doc/todo/object_dir_reorg_v2/comment_7_42501404c82ca07147e2cce0cff59474._commen view

file too large to diff

− doc/todo/object_dir_reorg_v2/comment_7_42501404c82ca07147e2cce0cff59474._comment

file too large to diff

+ doc/todo/parallel_possibilities/comment_1_d8e34fc2bc4e5cf761574608f970d496._com view

file too large to diff

− doc/todo/parallel_possibilities/comment_1_d8e34fc2bc4e5cf761574608f970d496._comment

file too large to diff

+ doc/todo/parallel_possibilities/comment_2_adb76f06a7997abe4559d3169a3181c3._com view

file too large to diff

− doc/todo/parallel_possibilities/comment_2_adb76f06a7997abe4559d3169a3181c3._comment

file too large to diff

+ doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._commen view

file too large to diff

− doc/todo/tahoe_lfs_for_reals/comment_1_0a4793ce6a867638f6e510e71dd4bb44._comment

file too large to diff

+ doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._commen view

file too large to diff

− doc/todo/tahoe_lfs_for_reals/comment_2_80b9e848edfdc7be21baab7d0cef0e3a._comment

file too large to diff

+ doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_dupli view

file too large to diff

− doc/todo/wishlist:_Provide_a___34__git_annex__34___command_that_will_skip_duplicates.mdwn

file too large to diff

+ doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote. view

file too large to diff

− doc/todo/wishlist:_special-case_handling_of_Youtube_URLs_in_Web_special_remote.mdwn

file too large to diff

+ doc/todo/wishlist:_swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._co view

file too large to diff

− doc/todo/wishlist:_swift_backend/comment_1_e6efbb35f61ee521b473a92674036788._comment

file too large to diff

+ doc/todo/wishlist:_swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._co view

file too large to diff

− doc/todo/wishlist:_swift_backend/comment_2_5d8c83b0485112e98367b7abaab3f4e3._comment

file too large to diff

+ doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._com view

file too large to diff

− doc/walkthrough/adding_a_remote/comment_1_0a59355bd33a796aec97173607e6adc9._comment

file too large to diff

+ doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._com view

file too large to diff

− doc/walkthrough/adding_a_remote/comment_2_f8cd79ef1593a8181a7f1086a87713e8._comment

file too large to diff

+ doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._com view

file too large to diff

− doc/walkthrough/adding_a_remote/comment_3_60691af4400521b5a8c8d75efe3b44cb._comment

file too large to diff

+ doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._com view

file too large to diff

− doc/walkthrough/adding_a_remote/comment_4_6f7cf5c330272c96b3abeb6612075c9d._comment

file too large to diff

+ doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comm view

file too large to diff

− doc/walkthrough/removing_files/comment_1_cb65e7c510b75be1c51f655b058667c6._comment

file too large to diff

+ doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comm view

file too large to diff

− doc/walkthrough/removing_files/comment_2_64709ea4558915edd5c8ca4486965b07._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_2_365db5820d96d5daa62c19fd76fcdf1e._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_2_451fd0c6a25ee61ef137e8e5be0c286b._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_3_b2f15a46620385da26d5fe8f11ebfc1a._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_4_433ccc87fbb0a13e32d59d77f0b4e56c._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_5_a9805c7965da0b88a1c9f7f207c450a1._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_6_9d5c12c056892b706cf100ea01866685._comment

file too large to diff

+ doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._c view

file too large to diff

− doc/walkthrough/using_ssh_remotes/comment_7_725e7dbb2d0a74a035127cb01ee0442c._comment

file too large to diff

+ git-annex-shell.1 view

file too large to diff

+ git-annex.1 view

file too large to diff

git-annex.cabal view

file too large to diff

+ make-sdist.sh view

file too large to diff