diff options
9 files changed, 114 insertions, 0 deletions
diff --git a/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment new file mode 100644 index 000000000..17ac4c275 --- /dev/null +++ b/doc/backends/comment_8_c40d2c2c929ad3239ee5d529e307c746._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 8" + date="2014-08-12T18:00:46Z" + content=""" +Ævar, you can use `git annex add --backend=SHA256` to temporarily override the backend. +"""]] diff --git a/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment new file mode 100644 index 000000000..4d7246eda --- /dev/null +++ b/doc/bugs/direct_command_leaves_repository_inconsistent_if_interrupted/comment_1_770e6ed8556fa6b259f517d5c398271f._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T17:26:46Z" + content=""" +The way it's supposed to work is that `git annex direct` does not set the repository into direct mode until it's entirely done moving files around. So, if it is interrupted at any point, you are left with an indirect mode repository, with some unlocked files. Which can be put back to indirect by `git annex add`, or the conversion restarted with `git annex direct`. + +That seems to work in my tests; I can interrupt `git annex direct` and resume with `git annex direct` with a good result; `git annex add` reverts back to indirect mode. Even `git commit -a` reverts back to indirect mode, thanks to the pre-commit hook. I have tested that all these recovery methods work as intended. + +That leaves `git annex lock --force` (it has to be forced) after an interrupted switch to direct mode. I have reproduced that in this situation, that will delete your file's contents (I cannot reproduce them ending up in misctmp, but [[!commit d8be828734704c78f91029263b59eed75174e665]] may have had something to do with that). In a sense, `git annex lock --force` is doing what you told it to -- git-annex lock throws unlocked file contents away, under the assumption that they might contain modified changes. Since normally, `git annex unlock` makes a copy of the file, there is not normally data loss, unless the unlocked files got modified. But that's why it requires the --force; it can result in data loss. + +I a having a hard time thinking of a modification to `git annex lock` that would make sense. The best I can come up with is, if the file's content is not present in the annex, it could switch to what `git annex add` does, and re-add the file content to the annex if it's unchanged. While, I guess, throwing away the content if it is changed. That seems a bit complicated. + +(BTW, if you do still have the files in misctmp, you can `git annex import` their content back into the repository.) +"""]] diff --git a/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment new file mode 100644 index 000000000..c4d78fa03 --- /dev/null +++ b/doc/bugs/git_annex_import_fails_on_filenames_with_newlines_in_them/comment_1_249b198e1141e05fe39f49bd7ad8870e._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T18:24:57Z" + content=""" +Congrats on being the guy with newlines in his filenames.. someone had to do it! + +Similarly, `git annex add` on the file will fail with the same error and leave it where it is and not added. + +The problem here is that while git-annex is careful to use git commands with -z, so it gets \"foo\nbar\" with a literal newline from git ls-files, `git cat-file --batch` speaks a line-based protocol. And, it parses filenames like `git ref-parse` does -- and AFAICS, that does not provide a way to input something like \"foo\\nbar\" with an escaped newline. Normally this doesn't matter, since the whole line of input is taken to be a filename, so there's no need to escape anything, but of course it fails with newlines. + +IMHO, the solution to this is to make `git cat-file --batch` have a -z option that enables NUL-delimited input (and probably output). If you want to see this happen, take it to the git developers.. + +(Should git annex import put files back if it fails to add them rather than leaving them sitting in the work tree?) +"""]] diff --git a/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment new file mode 100644 index 000000000..1303a2077 --- /dev/null +++ b/doc/bugs/googlemail/comment_2_bdb2b08346673f850709041d2f41be5c._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T17:39:09Z" + content=""" +AFAICS, xmpp.l.google.com is the correct XMPP server; it's what the SRV record for googlemail.com says to use. + +Since it fails with an authentication error, I wonder if google's XMPP is rejecting a user@googlemail.com jid and expects the domain to be @gmail.com or something else. Would that be allowed by the XMPP spec? I don't know. + + +"""]] diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment new file mode 100644 index 000000000..5775addc0 --- /dev/null +++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_1_f119d2b322a7b33c08b8187deba690c2._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 1" + date="2014-08-12T17:29:16Z" + content=""" +I don't seem to reproduce this bug when I run the script provided. + +<pre> +whereis fileA (1 copy) + c311d5b9-2f59-4153-a0e5-61707edd28ef -- pc1 +ok +whereis fileB (1 copy) + c311d5b9-2f59-4153-a0e5-61707edd28ef -- pc1 +ok +</pre> +"""]] diff --git a/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment new file mode 100644 index 000000000..d139aed36 --- /dev/null +++ b/doc/bugs/whereis_does_not_work_in_direct_mode/comment_2_d1005e29c32bddad109dd426d4dd8803._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T17:33:25Z" + content=""" +It seems to me that there are only 3 ways that pc2 could not know that pc1 has the file, in decreasing order of probability: + +1. pc1 has not pushed git-annex branch to origin (or pushed it after pc2 pulled) +2. pc2 has not fetched git-annex branch from origin +3. an actual bug, such as bad info being written to the git-annex branch or the git-annex branch merge failing + +So, if you have 3 repositories that exhibit a problem like this, those are the things to check. +"""]] diff --git a/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment new file mode 100644 index 000000000..74a3a2a75 --- /dev/null +++ b/doc/forum/Somehow_have_lots_of_directories_in_root:_000...ffff/comment_4_8c817d08ca9d94a1228fb21cd0b15744._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 4" + date="2014-08-12T17:50:15Z" + content=""" +Sure, it's fine to delete the files. The same info will be committed to git either way. +"""]] diff --git a/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment new file mode 100644 index 000000000..8591e79aa --- /dev/null +++ b/doc/forum/Using_git-annex_as_a_library/comment_6_45d9520ebc13d1b4fd88c25abc61f1b4._comment @@ -0,0 +1,11 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 6" + date="2014-08-12T17:48:34Z" + content=""" +There are a couple of problems with using the haskell code as a library that would need to be addressed: + +* I can't guarantee much about providing every interface in a compatible way going forward. It might make sense to pick out some key interfaces and make those stable, but I don't know what the right choices would be. +* If all of git-annex is a library, `cabal build` will build everything a second time. This is annoying when trying to do a fast edit/build/test cycle, but I don't know a way to make cabal not do it. AFAIK cabal build flags cannot be used to disable building a library. +"""]] diff --git a/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment new file mode 100644 index 000000000..e9122c069 --- /dev/null +++ b/doc/forum/__34__Lost__34___data__63___Maybe_a_bug__63__/comment_2_4d80b96e788d233706fa8f3e363d2f76._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + ip="209.250.56.7" + subject="comment 2" + date="2014-08-12T17:57:26Z" + content=""" +views are a somewhat new feature that still needs work, and you will find this question of what to do about a file added while in a view in the todo list [[here|design/metadata]]. + +Since views are just git branches, you can check out the view branch where you added the file, and it'll still be there. You could merge the branch (probably not a good idea since the filenames are moved around in the view). + +Using `fromkey` will also work, if you have the right key and the content is present in the annex -- I just tested it. +"""]] |