Merge remote-tracking branch 'branchable/master'

7 files changed, 77 insertions, 0 deletions

diff --git a/doc/bugs/Unfortunate_interaction_with_Calibre.mdwn b/doc/bugs/Unfortunate_interaction_with_Calibre.mdwn
new file mode 100644
index 000000000..d00a6720c
--- /dev/null
+++ b/doc/bugs/Unfortunate_interaction_with_Calibre.mdwn
@@ -0,0 +1,21 @@
+# Calibre 
+
+Calibre is a somewhat popular eBook management package that's also free software.  <http://calibre-ebook.com/>  
+
+Install via
+    # apt-get install calibre
+
+There is a somewhat unfortunate interaction between Calibre and git-annex...
+
+* git-annex makes its files become read-only.  By the way, that's not quite obvious from the documentation; I suggest making that more prominent.
+* Calibre modifies files (not quite sure of semantics, how, or why) when doing various operations, notably such as when copying a book from one's library to one's portable reading device.
+
+These don't play well together, sadly.
+
+I'd expect most of the issue to sit on the Calibre side, and have reported it as a bug.
+[Calibre bug #739045](https://bugs.launchpad.net/calibre/+bug/739045)
+Preliminary indication is that they're treating it as a functionality change they'll decline to fix.  Which isn't entirely unreasonable - I anticipated as much, and I don't want to treat that as a bad/wrong decision.
+
+However, I think it's:
+* Unfortunate, as fitting Calibre together with git-annex seems like a neat idea.
+* Useful to make sure that this kind of "doesn't play well together" condition is documented, even if only as a bug report.
diff --git a/doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment b/doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment
new file mode 100644
index 000000000..93db97e70
--- /dev/null
+++ b/doc/bugs/git_rename_detection_on_file_move/comment_5_d61f5693d947b9736b29fca1dbc7ad76._comment
@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="praet"
+ ip="81.242.56.203"
+ subject="comment 5"
+ date="2011-03-21T19:58:34Z"
+ content="""
+In the meantime, would it be acceptable to split the pre-commit hook
+into two discrete parts?
+
+This would allow to (if preferred) defer \"git annex fix\" until
+post-commit while still keeping the safety net for unlocked files.
+"""]]
diff --git a/doc/bugs/softlink_atime.mdwn b/doc/bugs/softlink_atime.mdwn
index 0d26d1ce6..69d6f6600 100644
--- a/doc/bugs/softlink_atime.mdwn
+++ b/doc/bugs/softlink_atime.mdwn
@@ -37,3 +37,13 @@ Optionally, editing the meta-data should change the times in all annexes.
 	git add .metadata
 
 >>>>>> Thanks a lot. Doing this in a new git-annex repo from the start should at least ensure local consistency and I assume I can simply add a post-pull hook to restore the mtimes on all all other repositories? -- RichiH
+
+>>>>>>> This is even better:
+
+    #!/bin/sh
+    git annex pre-commit .
+    which metastore || echo "$0: metastore is not installed; exiting"; exit 99
+    metastore --save
+    git add .metadata
+
+>>>>>>> -- RichiH
diff --git a/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment
new file mode 100644
index 000000000..56a7eb360
--- /dev/null
+++ b/doc/bugs/touch.hsc_has_problems_on_non-linux_based_systems/comment_8_881aecb9ae671689453f6d5d780d844b._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 8"
+ date="2011-03-21T08:52:18Z"
+ content="""
+Just tried building both of the code paths, and they seem to build and somewhat function on OSX. I have yet to confirm the functionality is working correctly, but so far it's looking good. (I somewhat care less about the utimes/mtimes of my files since I care more about the content :) )
+"""]]
diff --git a/doc/download/comment_1_fbd8b6d39e9d3c71791551358c863966._comment b/doc/download/comment_1_fbd8b6d39e9d3c71791551358c863966._comment
new file mode 100644
index 000000000..488e00527
--- /dev/null
+++ b/doc/download/comment_1_fbd8b6d39e9d3c71791551358c863966._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="http://peter-simons.myopenid.com/"
+ ip="84.189.2.244"
+ subject="Please provide stable tarballs or zipfiles"
+ date="2011-03-22T13:06:58Z"
+ content="""
+I'm trying to package git annex for ArchLinux and NixOS. That task would be a *lot* easier, if there were proper release archives available for download. The Gitweb site offers to create snapshot tarballs on the fly, but those tarballs have a different SHA hash every time they're generated, so they cannot be used for the purposes of a distribution. A simple solution for this problem would be to enable snapshots in zip format (because zip files look the same every time they're generated).
+"""]]
diff --git a/doc/download/comment_2_f85f72b33aedc3425f0c0c47867d02f3._comment b/doc/download/comment_2_f85f72b33aedc3425f0c0c47867d02f3._comment
new file mode 100644
index 000000000..5441c3e4c
--- /dev/null
+++ b/doc/download/comment_2_f85f72b33aedc3425f0c0c47867d02f3._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus"
+ nickname="Jimmy"
+ subject="comment 2"
+ date="2011-03-22T14:01:37Z"
+ content="""
+maybe snag tarballs from <http://packages.debian.org/experimental/git-annex> ? 
+"""]]
diff --git a/doc/download/comment_3_cf6044ebe99f71158034e21197228abd._comment b/doc/download/comment_3_cf6044ebe99f71158034e21197228abd._comment
new file mode 100644
index 000000000..b72b848f8
--- /dev/null
+++ b/doc/download/comment_3_cf6044ebe99f71158034e21197228abd._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 3"
+ date="2011-03-22T18:09:21Z"
+ content="""
+The tarballs produced by gitweb are actually stable. They are wrapped in a gz file with a varying timestamp however. It might be nice if gitweb passed --no-name to gzip to avoid that inconsistency.
+
+git-annex also has a [pristine-tar](http://kitenet.net/~joey/code/pristine-tar/) branch in git that can be used to recreate the tarballs I upload to Debian.
+"""]]