From 45c72cf9c3f2f4f2c3e2e6b05549f9695acec561 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 18:56:11 +0000 Subject: [PATCH 01/10] Added a comment --- ...comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/Relocating_annex_directory/comment_2_6d88ff03fcf00ae872442e8a86c968ed._comment 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 0000000000..e7b361675f --- /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. +"""]] From 869365aad4fbc5dd7cc244f374a1253b576d87d8 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:10:21 +0000 Subject: [PATCH 02/10] Added a comment --- ...nt_9_419e24e0b91f569294ece28c42daa246._comment | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 doc/bugs/Resource_exhausted/comment_9_419e24e0b91f569294ece28c42daa246._comment 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 0000000000..0e06f5af92 --- /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. +"""]] From 3e5bc04cd782325096cef13f2bb7ead5d0a31f51 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:17:29 +0000 Subject: [PATCH 03/10] Added a comment: bad bug report title 101 --- ...comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Windows_to_Linux_clone_-_Windows_drive_letters_cause_git_annex_get_to_fail/comment_2_9e3c1f1ba05d8996b5a95829ce32c07e._comment 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 0000000000..d98e7976e3 --- /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. +"""]] From f09add064bd413f82256f1d6f04621f3c02dbd6d Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:22:06 +0000 Subject: [PATCH 04/10] Added a comment --- ...comment_1_0a6f6054d70009979f4a036e24b7c500._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/USB_drive_in_transfer_group_keeps_growing_-_assistant/comment_1_0a6f6054d70009979f4a036e24b7c500._comment 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 0000000000..f298b56cde --- /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). +"""]] From 837febd0985883dd46b9ae0d8acf66bf5ee7f2df Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:27:57 +0000 Subject: [PATCH 05/10] Added a comment --- ...mment_3_f34d996827f5e7662bec409cbcce961b._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/Can__39__t_clone_on_Windows_because_some_filenames_have_a_colon_in_them/comment_3_f34d996827f5e7662bec409cbcce961b._comment 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 0000000000..14cfa2686e --- /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. +"""]] From f3682ba9a4787e76c0f67ed56475e03180376f9e Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:37:49 +0000 Subject: [PATCH 06/10] cool feature design --- .../wishlist:_dropping_git-annex_history.mdwn | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/todo/wishlist:_dropping_git-annex_history.mdwn 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 0000000000..b19bde842b --- /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]] From 01a238da15f4e5feecf1afde88f93c353d315fbe Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:39:45 +0000 Subject: [PATCH 07/10] Added a comment --- ...comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/wishlist:_dropping_git-annex_history/comment_1_a4bee2e26b22a9bdaadc05b7227769ef._comment 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 0000000000..043e674ed8 --- /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. ;) +"""]] From fec7e7aae4ee48d3d7941e3e29470be464810fe2 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:48:46 +0000 Subject: [PATCH 08/10] Added a comment --- ...comment_2_faefcf69bd61c47566131cb31b78cc19._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/git_annex_add_error_with_Andrew_File_System/comment_2_faefcf69bd61c47566131cb31b78cc19._comment 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 0000000000..a2301499cb --- /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? +"""]] From 3e4c191bbc4a4cf6d18723e8be8620468eef4877 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:55:56 +0000 Subject: [PATCH 09/10] Added a comment: seems like a general git problem --- ...mment_1_e074b20801b921ee2661025a050a8af2._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/test_suite_failure_on_samba_mount/comment_1_e074b20801b921ee2661025a050a8af2._comment 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 0000000000..623028c80c --- /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. +"""]] From f22cfb5767969a2b521eadd5c2bdb4dc180ffba7 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sat, 24 Aug 2013 19:58:54 +0000 Subject: [PATCH 10/10] Added a comment --- ...comment_1_38af9b352020194e9ace34d7dde188cf._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/todo/add_metadata_to_annexed_files/comment_1_38af9b352020194e9ace34d7dde188cf._comment 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 0000000000..8460300a79 --- /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. +"""]]