Merge remote-tracking branch 'branchable/master'

4 files changed, 37 insertions, 0 deletions

diff --git a/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_10_f3594de3ba2ab17771a4b116031511bb._comment b/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_10_f3594de3ba2ab17771a4b116031511bb._comment
new file mode 100644
index 000000000..c3e6b5e59
--- /dev/null
+++ b/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_10_f3594de3ba2ab17771a4b116031511bb._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 10"
+ date="2011-04-01T16:11:52Z"
+ content="""
+No, I don't need a copy of your repo now.
+"""]]
diff --git a/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_9_45b11ddd200261115b653c7a14d28aa9._comment b/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_9_45b11ddd200261115b653c7a14d28aa9._comment
new file mode 100644
index 000000000..8dfe74642
--- /dev/null
+++ b/doc/bugs/git-annex_directory_hashing_problems_on_osx/comment_9_45b11ddd200261115b653c7a14d28aa9._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 9"
+ date="2011-03-31T21:32:10Z"
+ content="""
+I'm was running git 1.7.4.1 at the time when I came across it, I have just upgraded to 1.7.4.2. I've also just moved to using a loopback fs for the stuff i care about. Do you still want a repo that exhibits the problem (excluding the .git/annex data) ??? I'm also not sure if 1.7.4.2 has corrected the problem yet as I haven't done much with my repos since. I suspect just making all the .git-annex hashed directories seems to be lower case might be better in the long run. 
+"""]]
diff --git a/doc/bugs/git_annex_copy_--fast_does_not_copy_files.mdwn b/doc/bugs/git_annex_copy_--fast_does_not_copy_files.mdwn
new file mode 100644
index 000000000..ada844a14
--- /dev/null
+++ b/doc/bugs/git_annex_copy_--fast_does_not_copy_files.mdwn
@@ -0,0 +1,18 @@
+Workflow:
+
+    % git annex add
+      # list new files
+    % git commit -a -m "foo"
+      # commit summary
+    % git annex copy . --to remote --fast
+      # all files listed with "ok"
+    % git annex copy . --to remote
+      # again, lists all files, _but the new ones are actually copied, this time_.
+
+This happens no matter if I
+
+    % git push
+
+before copy or not.
+
+PS: Arguably, a copy should push automagically.
diff --git a/doc/bugs/softlink_atime.mdwn b/doc/bugs/softlink_mtime.mdwn
index fe09ade38..1427fc714 100644
--- a/doc/bugs/softlink_atime.mdwn
+++ b/doc/bugs/softlink_mtime.mdwn
@@ -49,3 +49,6 @@ Optionally, editing the meta-data should change the times in all annexes.
 >>>>>>> -- RichiH
 
 >>>>>>>> After getting to actually play with this from different machines with a bare git as central instance for several distributed repos, the metastore trick does not work. The .metadata is causing merge conflicts for every pull. I removed the "done" tag from this issue. -- RichiH
+
+>>>>>>>>> softbox sounds _really_ nice. File systems need to preserve mtimes. Oviously, it would be nice if git-annex exposed this to the upper layer instead of relying on this FUSE implementation, or the next, or the other totally cool thing around the corner to implement it again and again. 
+>>>>>>>>> I talked to the author of metastore; he is aware that the format is merge-unfriendly but never needed merges for himself. He is aware that this is not ideal for something like git. He does not have the time to implement a text storage instead of binary and I lack the skills to do it. If metastore is used, all it would need to do is introduce a new version of the store (it's versioned, apparently) and save metadata in text, one file per line. xattr would need to be ASCII-armoured, the rest could be plain text. I still think storing this directly in git-annex would make the most sense. Introducing a metadata storage file per storage object in .git/annex and using the object file's name as index is impossible because several softlinks might point to one object so it would need to be done per-softlink :/ -- RichiH