Merge branch 'master' of ssh://git-annex.branchable.com

10 files changed, 117 insertions, 0 deletions

diff --git a/doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_3_f34d996827f5e7662bec409cbcce961b._comment b/doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_3_f34d996827f5e7662bec409cbcce961b._comment
new file mode 100644
index 000000000..14cfa2686
--- /dev/null
+++ b/doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_3_f34d996827f5e7662bec409cbcce961b._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 3"
+ date="2013-08-24T19:27:57Z"
+ content="""
+Leonardo, you made me boot up my windows machine just to check if cygwin git truncated files at the colon. It does not.
+
+AFAIK, Cygwin transliterates colons to another unicode character or something like that. I would be highly surprised if the Cygwin people consider this feature to be a bug.
+
+Since you need Cygwin to build git-annex on Windows anyway (though not to run it!), this remains WONTFIX.
+"""]]
diff --git a/doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment b/doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment
new file mode 100644
index 000000000..0e06f5af9
--- /dev/null
+++ b/doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment
@@ -0,0 +1,15 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 9"
+ date="2013-08-24T19:10:21Z"
+ content="""
+@Michael how large a copy are you doing? And what kind of remote are you copying the files to?
+It would be helpful if you could be more specific about something I could do to reproduce the problem. Without a test case, I am unlikely to fix the bug. With a test case, I'd be surprised if it took long to fix it.
+
+If you have a process running that is experiencing the problem, you can also narrow it down a *lot* by looking at what these leaking pipe file descriptors are pipes to.  For example, if you have:
+
+lr-x------ 1 michael michael 64 Aug 10 20:14 895 -> pipe:[2251602]
+
+You can run `find /proc/ -ls 2251602` and find the process at other end of the pipe, and look its pid up in ps to see what command it is.
+"""]]
diff --git a/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment
new file mode 100644
index 000000000..d98e7976e
--- /dev/null
+++ b/doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="bad bug report title 101"
+ date="2013-08-24T19:17:29Z"
+ content="""
+I don't understand why you think the problem has something to do with Windows drive letters. There are no Windows drive letters in the symlinks you show. The only place I see any Windows drive letter is in the descripton of the remote that `git annex get` displays when it fails to get the file. That description is purely informative, it's not a path that git-annex is trying to use.
+
+I'd suggest that you run `git annex get --debug` to see if it is doing anything obviously wrong. The mostly likely culprit is your SMB setup, which I am not going to be able to replicate.
+"""]]
diff --git a/doc/bugs/git_annex_add_error_with_Andrew_File_System/comment_2_faefcf69bd61c47566131cb31b78cc19._comment b/doc/bugs/git_annex_add_error_with_Andrew_File_System/comment_2_faefcf69bd61c47566131cb31b78cc19._comment
new file mode 100644
index 000000000..a2301499c
--- /dev/null
+++ b/doc/bugs/git_annex_add_error_with_Andrew_File_System/comment_2_faefcf69bd61c47566131cb31b78cc19._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 2"
+ date="2013-08-24T19:48:46Z"
+ content="""
+I'm confused by this bug report, because it seems to me I already fixed this same problem in commit a64106dcef5c5aad825662ef115cb2a1cc6985a8. There the problem was that encfs in paranoia mode doesn't support hard links. So I made it detect when createLink fails, and fall back to a code path that doesn't need hard links.
+
+Can you re-check the version you have, and perhaps try with a current daily build?
+"""]]
diff --git a/doc/bugs/test_suite_failure_on_samba_mount/comment_1_e074b20801b921ee2661025a050a8af2._comment b/doc/bugs/test_suite_failure_on_samba_mount/comment_1_e074b20801b921ee2661025a050a8af2._comment
new file mode 100644
index 000000000..623028c80
--- /dev/null
+++ b/doc/bugs/test_suite_failure_on_samba_mount/comment_1_e074b20801b921ee2661025a050a8af2._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="seems like a general git problem"
+ date="2013-08-24T19:55:56Z"
+ content="""
+\"unable to create temporary sha1 filename\" is a git error message. I don't actually see any git-annex failure here, just a git failure that seems to lead to a cascade of other failures. 
+
+I'm not sure if the \"/media/freebox/.t/tmprepo3/.git: No such file or directory\" is because git clone has failed due to the other errors, or if git clone somehow failed to set up the .git directory.
+
+It would probably be helpful to have a play around with git on this filesystem and see what breaks. Alternatively, you can use git-annex with `--debug` to see the git commands it's running that fail, and try them yourself and perhaps strace or gdb them or something to see where they go wrong.
+"""]]
diff --git a/doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment b/doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment
new file mode 100644
index 000000000..e7b361675
--- /dev/null
+++ b/doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 2"
+ date="2013-08-24T18:56:11Z"
+ content="""
+`git annex whereis` does not show dead repositories. 
+
+Anyway Justin is of course right: Provided the assistant is not running in a repository, the repository is just a collection of files in a directory, and can be moved around, tarred up, untarred, etc just like any other repository. If the assistant is running it may become unhappy if its repository vanishes out from underneath it.
+"""]]
diff --git a/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment
new file mode 100644
index 000000000..f298b56cd
--- /dev/null
+++ b/doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-24T19:22:05Z"
+ content="""
+The assistant is supposed to remove files from transfer repositories once the file has been transferred to all known clients.  This generally seems to work, with all the transfer repositories I've tested it with. Nothing is special about USB drives compared with other transfer repositories.
+
+Perhaps you have not configured the USB drive as a transfer repository? Or perhaps you have another client repository (even a client repository you had once but have now deleted).
+"""]]
diff --git a/doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment b/doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment
new file mode 100644
index 000000000..8460300a7
--- /dev/null
+++ b/doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-24T19:58:54Z"
+ content="""
+I don't know if git-annex is the right vehicle to fix this. It seems that a more generic fix that would work in non-git-annex repos would be better.
+
+I can answer your question though: The metadata such as urls and locations that git-annex stores in the git-annex branch is attached to objects, and not to work tree paths.
+"""]]
diff --git a/doc/todo/wishlist:_dropping_git-annex_history.mdwn b/doc/todo/wishlist:_dropping_git-annex_history.mdwn
new file mode 100644
index 000000000..b19bde842
--- /dev/null
+++ b/doc/todo/wishlist:_dropping_git-annex_history.mdwn
@@ -0,0 +1,18 @@
+In real life discussions with git-annex users at DebConf, the idea was proposed to have a way to drop the history of the git-annex branch, and replace it with a new branch with just the current state of the repository. 
+
+The only thing that breaks when this is done, in theory, is `git annex log`, which can't show the location history 
+of files.
+
+The crucial thing is that this operation would only need to be done in one repository, and it would then record some information in its (new) git-annex branch, so when it was pushed to other repositories, git-annex there could notice that history had been dropped, and do the same. So, even if you have rarely used offline archive repositories, the history dropping would eventually reach them, without needing to remember to do it.
+
+There was speculation that it would be enough to record eg, the SHA of the top commit on the old branch. That may not be good enough, because another remote may have not gotten that SHA into its branch yet, or may have commits on top of that SHA. 
+
+Maybe instead we want to record the SHA of the *first* commit to the old git-annex branch. This way, we can tell if the branch that got deleted is the one we're currently using. And if it is, we create a new branch with the current state of *our* branch, and then union merge the other branch into it.
+
+Hmm, another wrinkle is that, when this indication propigates from remote A to remote B, remote B may also have some git-annex branches available for remotes C and D, which have not transitioned, and E, which has transitioned already. It seems B should first union merge C and D into B, and then flatten B to B', and then union merge A and E into B'.
+
+I think that'd work!
+
+--[[Joey]]
+
+See also : [[forum/safely_dropping_git-annex_history]]
diff --git a/doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment b/doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment
new file mode 100644
index 000000000..043e674ed
--- /dev/null
+++ b/doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.154.0.63"
+ subject="comment 1"
+ date="2013-08-24T19:39:45Z"
+ content="""
+BTW, a motivation for this is that some of us have old repositories that have been upgrades all the way from annex.version 1 and have a lot of cruft in them because of it. (I have repos that have been upgraded from annex.version 0, but this would not help with that cruft which is on the master branch!)
+
+Also, people worry that eg, a large copy back and forth bloats history, and having a way to unbloat it if it ever gets actually annoyingly bloated would stop them pestering me. ;)
+"""]]