From 537a5b83bbc780c3df5e6a5a6415e0d80872dd55 Mon Sep 17 00:00:00 2001 From: Richard Hartmann Date: Fri, 8 Mar 2013 11:17:31 +0100 Subject: [PATCH 1/9] s/Fosdem/FOSDEM/g --- doc/index.mdwn | 2 +- doc/videos/{Fosdem2012.mdwn => FOSDEM2012.mdwn} | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) rename doc/videos/{Fosdem2012.mdwn => FOSDEM2012.mdwn} (88%) diff --git a/doc/index.mdwn b/doc/index.mdwn index fadc27e6af..56cd9811a9 100644 --- a/doc/index.mdwn +++ b/doc/index.mdwn @@ -62,7 +62,7 @@ files with git.
-[[!inline raw=yes pages="videos/Fosdem2012"]] +[[!inline raw=yes pages="videos/FOSDEM2012"]] [[!inline raw=yes pages="videos/LCA2013"]] diff --git a/doc/videos/Fosdem2012.mdwn b/doc/videos/FOSDEM2012.mdwn similarity index 88% rename from doc/videos/Fosdem2012.mdwn rename to doc/videos/FOSDEM2012.mdwn index 27a8e9ec3a..c1a381939b 100644 --- a/doc/videos/Fosdem2012.mdwn +++ b/doc/videos/FOSDEM2012.mdwn @@ -1,4 +1,4 @@
A 15 minute introduction to git-annex, -presented by Richard Hartmann at Fosdem 2012. +presented by Richard Hartmann at FOSDEM 2012. From e989539a8a395b0e5116c78039acf01fa0c2fdcb Mon Sep 17 00:00:00 2001 From: guilhem Date: Fri, 8 Mar 2013 14:25:20 +0000 Subject: [PATCH 2/9] --- doc/forum/wishlist:_GnuPG_options.mdwn | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/forum/wishlist:_GnuPG_options.mdwn diff --git a/doc/forum/wishlist:_GnuPG_options.mdwn b/doc/forum/wishlist:_GnuPG_options.mdwn new file mode 100644 index 0000000000..aa11f13caa --- /dev/null +++ b/doc/forum/wishlist:_GnuPG_options.mdwn @@ -0,0 +1,14 @@ +[Maybe I should have on [[this thread|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/]], but I figured I'd make my own since it's perhaps too old.] + +I second Justin and [[his idea|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/#comment-e120f8ede0d4cffce17cbf84564211c1]] of having per-remote GnuPG options. I'd even go one step further, and propose the option in the .gitattributes file. Indeed by default GnuPG compresses the data before encryption, which doesn't make a lot of sense for git-annex (in my use-case at least); My work-around to save this waste of CPU cycles was to customize my gpg.conf, but it's somewhat dirty since I do want to use compression in general. + +Here is how I envision the .git/config: +
    [annex]
+        gnupg-options = --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo none
+
+ +And compression could be enabled on say, text files, with a suitable wildcard in the .gitattributes file. +
    *.txt annex.gnupg-options = --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo zlib
+
+ +This is something I could probably hack on if you think it'd be a worthwhile option ;-) From dfc68e4db7d8d4d613420a797967b05db8e9fd30 Mon Sep 17 00:00:00 2001 From: "http://edheil.wordpress.com/" Date: Fri, 8 Mar 2013 14:46:55 +0000 Subject: [PATCH 3/9] Added a comment --- ...nt_8_78e6164ef67a9560a3a9ead1f7a72473._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment diff --git a/doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment b/doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment new file mode 100644 index 0000000000..c49cbbeefc --- /dev/null +++ b/doc/bugs/__39__client__39___repo_starts_pulling_in___39__archive__39___content/comment_8_78e6164ef67a9560a3a9ead1f7a72473._comment @@ -0,0 +1,15 @@ +[[!comment format=mdwn + username="http://edheil.wordpress.com/" + ip="173.162.44.162" + subject="comment 8" + date="2013-03-08T14:46:55Z" + content=""" +I've not seen this kind of strange behavior happen again so far. + +But I have got another example of a file which I added to git-annex via the assistant not having its symlink added to git. Again, the content of the file is in git-annex and was even correctly transferred to a couple of remotes, but the symlink is still unstaged. + +I tried restarting the assistant to see if that would fix it but that didn't change anything. + +I imagine the symlink will be fixed during a daily scan, tomorrow maybe? Is it problematic for the symlink not to be checked into git for a day? Is this worth a bug report or is this really harmless behavior? + +"""]] From 71e4e30ab9d419f76b1beb06b0fb43160c7e4d19 Mon Sep 17 00:00:00 2001 From: guilhem Date: Fri, 8 Mar 2013 16:06:05 +0000 Subject: [PATCH 4/9] --- ...iles_containing_ISO8859-15_characters.mdwn | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn diff --git a/doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn b/doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn new file mode 100644 index 0000000000..4ec042840d --- /dev/null +++ b/doc/bugs/git-annex_doesn__39__t_list_files_containing_ISO8859-15_characters.mdwn @@ -0,0 +1,35 @@ +

What steps will reproduce the problem?

+
    git init /tmp/test
+    cd /tmp/test
+    git annex init
+    touch òó ō
+    git annex add òó ō
+    git annex find --include='*'
+
+ +

What is the expected output? What do you see instead?

+Only ō is listed. Files containing ISO8859-15 characters that are not in ASCII-7, such as òó, are not listed by +git annex find --include='*'. On the other hand, git annex find --in=here lists both. + +

What version of git-annex are you using? On what operating system?

+git-annex 4.20130227, on Debian GNU/Linux (sid, i386). + +

Please provide any additional information below.

+
    ~$ locale
+    LANG=en_US.UTF-8
+    LANGUAGE=en
+    LC_CTYPE="en_US.UTF-8"
+    LC_NUMERIC=C
+    LC_TIME=en_DK.UTF-8
+    LC_COLLATE="en_US.UTF-8"
+    LC_MONETARY="en_US.UTF-8"
+    LC_MESSAGES="en_US.UTF-8"
+    LC_PAPER=sv_SE.UTF-8
+    LC_NAME=sv_SE.UTF-8
+    LC_ADDRESS=sv_SE.UTF-8
+    LC_TELEPHONE=sv_SE.UTF-8
+    LC_MEASUREMENT=sv_SE.UTF-8
+    LC_IDENTIFICATION="en_US.UTF-8"
+    LC_ALL=
+
+ From 736aee4274ee32d6ff438439ab04faf3d1843c69 Mon Sep 17 00:00:00 2001 From: guilhem Date: Fri, 8 Mar 2013 16:51:51 +0000 Subject: [PATCH 5/9] --- doc/forum/wishlist:_GnuPG_options.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/forum/wishlist:_GnuPG_options.mdwn b/doc/forum/wishlist:_GnuPG_options.mdwn index aa11f13caa..4d8bfb4013 100644 --- a/doc/forum/wishlist:_GnuPG_options.mdwn +++ b/doc/forum/wishlist:_GnuPG_options.mdwn @@ -1,4 +1,4 @@ -[Maybe I should have on [[this thread|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/]], but I figured I'd make my own since it's perhaps too old.] +[Maybe I should have extented [[this thread|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/]], but I thought I'd make my own since it's perhaps too old.] I second Justin and [[his idea|http://git-annex.branchable.com/forum/wishlist:_simpler_gpg_usage/#comment-e120f8ede0d4cffce17cbf84564211c1]] of having per-remote GnuPG options. I'd even go one step further, and propose the option in the .gitattributes file. Indeed by default GnuPG compresses the data before encryption, which doesn't make a lot of sense for git-annex (in my use-case at least); My work-around to save this waste of CPU cycles was to customize my gpg.conf, but it's somewhat dirty since I do want to use compression in general. @@ -8,7 +8,7 @@ Here is how I envision the .git/config: And compression could be enabled on say, text files, with a suitable wildcard in the .gitattributes file. -
    *.txt annex.gnupg-options = --s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo zlib
+
    *.txt annex.gnupg-options="--s2k-cipher-algo AES256 --s2k-digest-algo SHA512 --s2k-count 8388608 --cipher-algo AES256 --compress-algo zlib"
 

 
 This is something I could probably hack on if you think it'd be a worthwhile option ;-)

From 507ea8708dba96d202bf4330984ddc20c3aca79a Mon Sep 17 00:00:00 2001
From: "http://joeyh.name/" 
Date: Fri, 8 Mar 2013 18:59:27 +0000
Subject: [PATCH 6/9] Added a comment

---
 ...t_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)
 create mode 100644 doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment

diff --git a/doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment b/doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment
new file mode 100644
index 0000000000..5f55f356bb
--- /dev/null
+++ b/doc/bugs/Rsync_encrypted_remote_asks_for_ssh_key_password_for_each_file/comment_1_fd95e0bb61e80a72b4ac1304ef6c2e77._comment
@@ -0,0 +1,16 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-08T18:59:27Z"
+ content="""
+git-annex does not use ssh connection caching for rsync special remotes, and so if you've configured ssh such that it needs to prompt for a password when making a connection, you'll be prompted twice for each file when using `git annex copy`: Once when it checks if the file is present, once when it rsyncs it. (One of those can be avoided by passing --fast)
+
+I don't see where a third password prompt can come from, other than gpg. But that would only prompt once per git-annex command, since git-annex caches the remote's encryption key.
+
+Of course, you can use a ssh-agent to avoid repeated ssh password prompts.
+
+----
+
+There's certainly a valid wishlist todo item that the rsync special remote should support ssh connection caching. It could be implemented using rsync -e. Although it would need to parse all valid rsync urls to determine which use ssh and which not, and what the user and hostname are.
+"""]]

From 64903749574a45b2c6d23a51c9554d4e19afff9a Mon Sep 17 00:00:00 2001
From: "http://joeyh.name/" 
Date: Fri, 8 Mar 2013 19:02:54 +0000
Subject: [PATCH 7/9] Added a comment

---
 ...comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment

diff --git a/doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment b/doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment
new file mode 100644
index 0000000000..82acacd756
--- /dev/null
+++ b/doc/bugs/Complete_failure_trying_to_unannex_a_large_annex/comment_1_1c202695ab7fe62cdc8770e1fb428d0c._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ nickname="joey"
+ subject="comment 1"
+ date="2013-03-08T19:02:54Z"
+ content="""
+You seem to have a corrupt .git/index file, or .git/annex/index, or maybe a whole corrupt git repository. I'm not sure. I'd start by running `git fsck`, and if that's ok, remove `.git/annex/index` and `.git/annex/index.lck`. git-annex will recover from that automatically. If that still doesn't help, you might need to delete .git/index and do some reset to get it back.
+
+I don't see much evidence of an actual bug here, just bad data that is somehow on disk.
+"""]]

From 4a710ca7574b300ae6960260dee35996881e91e1 Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawm6MkmwCd_-IACT0uzgy78u0qH1rPLNO_Q"
 
Date: Fri, 8 Mar 2013 19:07:54 +0000
Subject: [PATCH 8/9] Report of potential git annex get problem.

---
 ...__34__No_such_file_or_directory__34__.mdwn | 49 +++++++++++++++++++
 1 file changed, 49 insertions(+)
 create mode 100644 doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn

diff --git a/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn b/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
new file mode 100644
index 0000000000..a645504e75
--- /dev/null
+++ b/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
@@ -0,0 +1,49 @@
+**What steps will reproduce the problem?**
+I did a basic git annex setup with two repositories talking to each other.  They are on the same macine, but I identified them via the hostname, because I intend to set up my production systems on two machines.  Since I am new to annex, I'll reproduce the full sequence of commands to create the repos and sync them.  *I* noticed the trouble at the last step, when `git annex get` failed.
+
+Here is the full sequence of commands:
+
+    >>> cd /scr/wandschn/hackNtest/distributed/nyc/STU_files
+    >>> git init
+    >>> git annex init nyc
+    >>> cd /scr/wandschn/hackNtest/distributed/pdx
+
+    >>> git clone xerxes:/scr/wandschn/hackNtest/distributed/nyc/STU_files
+    >>> git annex init pdx
+    >>> git remote add nyc xerxes:/scr/wandschn/hackNtest/distributed/nyc/STU_files
+
+    >>> cd /scr/wandschn/hackNtest/distributed/nyc/STU_files
+    >>> git remote add pdx xerxes:/scr/wandschn/hackNtest/distributed/pdx/STU_files
+
+    >>> mkdir shared
+    >>> cp ../../../files/shared/* shared/.
+    >>> git annex add shared
+    >>> git commit -a -m "initial add of shared files"
+
+    >>> cd /scr/wandschn/hackNtest/distributed/pdx/STU_files
+    >>> git fetch nyc
+    >>> git merge nyc/master
+    >>> ls shared/135.mae
+    shared/135.mae
+    >>> git annex whereis shared/135.mae
+    whereis shared/135.mae (1 copy)
+            6f0368db-f1b1-4192-9200-3575c16c2ef1 -- origin (nyc)
+    ok
+    >>> git annex get shared/135.mae
+    fatal: Could not switch to '../.git/annex/objects/KV/5f/SHA256-s1499628--4a7e2ba13096ee2d1a6b3c3b314efae623516d200c09d35ff0f695395b6ad47a': No such file or directory
+
+    git-annex: : hGetLine: end of file
+    failed
+    git-annex: get: 1 failed
+
+**What is the expected output? What do you see instead?**
+I expected the file shared/135.mae to be copied from the remote repo to the local repo.  Instead, this command failed, and said that there was a missing file.  This file path is the one that the broken link points to, and it exists on the remote repo.
+
+**What version of git-annex are you using? On what operating system?**
+git version 1.7.9.6
+git-annex 3.20120523
+CentOS 6.3 (kernel 2.6.32)
+64bit Xeon processor
+
+
+**Please provide any additional information below.**

From c04be6e5af5ab8eebcd62867b9261ad88c8ae57d Mon Sep 17 00:00:00 2001
From: 
 "https://www.google.com/accounts/o8/id?id=AItOawm6MkmwCd_-IACT0uzgy78u0qH1rPLNO_Q"
 
Date: Fri, 8 Mar 2013 19:10:32 +0000
Subject: [PATCH 9/9] Formatting changes.

---
 ...ex_get_fails:___34__No_such_file_or_directory__34__.mdwn | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn b/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
index a645504e75..f3370fcb6d 100644
--- a/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
+++ b/doc/bugs/annex_get_fails:___34__No_such_file_or_directory__34__.mdwn
@@ -1,4 +1,5 @@
 **What steps will reproduce the problem?**
+
 I did a basic git annex setup with two repositories talking to each other.  They are on the same macine, but I identified them via the hostname, because I intend to set up my production systems on two machines.  Since I am new to annex, I'll reproduce the full sequence of commands to create the repos and sync them.  *I* noticed the trouble at the last step, when `git annex get` failed.
 
 Here is the full sequence of commands:
@@ -37,12 +38,17 @@ Here is the full sequence of commands:
     git-annex: get: 1 failed
 
 **What is the expected output? What do you see instead?**
+
 I expected the file shared/135.mae to be copied from the remote repo to the local repo.  Instead, this command failed, and said that there was a missing file.  This file path is the one that the broken link points to, and it exists on the remote repo.
 
 **What version of git-annex are you using? On what operating system?**
+
 git version 1.7.9.6
+
 git-annex 3.20120523
+
 CentOS 6.3 (kernel 2.6.32)
+
 64bit Xeon processor