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

6 files changed, 62 insertions, 1 deletions

diff --git a/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment b/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment
new file mode 100644
index 000000000..c1ba9f2f4
--- /dev/null
+++ b/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment
@@ -0,0 +1,22 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawmraN_ldJplGunVGmnjjLN6jL9s9TrVMGE"
+ nickname="Ævar Arnfjörð"
+ subject="How to convert bare repositories to non-bare"
+ date="2012-11-11T20:14:44Z"
+ content="""
+I made a repository bare and later wanted to convert it, this would have worked with just plain git:
+
+    cd bare-repo.git
+    mkdir .git
+    mv .??* * .git/
+    git config --unset core.bare
+    git reset --hard
+
+But because git-annex uses different hashing directories under bare repositories all the files in the repo will point to files you don't have. Here's how you can fix that up assuming you're using a backend that assigns unique hashes based on file content (e.g. the SHA256 backend):
+
+    mv .git/annex/objects from-bare-repo
+    git annex add from-bare-repo
+    git rm -f from-bare-repo
+
+
+"""]]
diff --git a/doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment
new file mode 100644
index 000000000..96dbc6a2e
--- /dev/null
+++ b/doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://christian.amsuess.com/chrysn"
+ nickname="chrysn"
+ subject="further tracking"
+ date="2012-11-11T01:15:41Z"
+ content="""
+the behavior is rooted in rsync, which behaves similar to `mkdir -p`. it can probably be worked around by configuring the rsync option `--chmod=775`, but that would add executability to files.
+
+i've opened a bug in rsync's bug tracker at <https://bugzilla.samba.org/show_bug.cgi?id=9377>, let's see what the developer says.
+"""]]
diff --git a/doc/bugs/network___62____61___2.4.0.1_is_not_in_Haskell_Platform_2012.4.0.0.mdwn b/doc/bugs/network___62____61___2.4.0.1_is_not_in_Haskell_Platform_2012.4.0.0.mdwn
new file mode 100644
index 000000000..98a893236
--- /dev/null
+++ b/doc/bugs/network___62____61___2.4.0.1_is_not_in_Haskell_Platform_2012.4.0.0.mdwn
@@ -0,0 +1,9 @@
+git-annex requires version 2.4.0.1 or later of the 'network' library. Unfortunately,
+the current version of the Haskell Platform mandates version 2.3.1.0 of that library.
+This means that git-annex cannot be compiled on the Haskell Platform 2012.4.0.0 (which
+is going to remain the HP version of choice until May next year or so).
+
+Do you think it's possible to support *both* versions of the network library, maybe?
+That would increase the portability of git-annex quite a bit.
+
+Thank you for your consideration.
diff --git a/doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment b/doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment
new file mode 100644
index 000000000..7ee62eea7
--- /dev/null
+++ b/doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://meep.pl/"
+ ip="193.23.174.18"
+ subject="xmlns"
+ date="2012-11-11T09:00:01Z"
+ content="""
+A minor point, but is saving a couple of bytes per message worth using a [deprecated feature](http://www.w3.org/TR/REC-xml-names/#iri-use) of the namespaces specification? This is not technically *breaking* the current specification, since \"git-annex\" is of course still a (relative) URI reference; and anyway chances of problems are, I guess, slim. But is it the lesser of two bugs?
+
+The shortest moderately sane absolute URI containing \"git-annex\" would probably be \"data:,git-annex\".
+"""]]
diff --git a/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment b/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment
new file mode 100644
index 000000000..f17fc5634
--- /dev/null
+++ b/doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment
@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="http://joeyh.name/"
+ ip="4.152.108.27"
+ subject="comment 1"
+ date="2012-11-11T16:06:42Z"
+ content="""
+I suspect you have an old build of the assistant. Version 3.20121009 was supposed to fix this.
+
+I re-tested with current git head today, and found I was able to unlock a file, repeatedly edit it in place without the assistant re-adding it, and then run \"git annex add\" and the assistant auto-committed the changed file. Better behavior than I was expecting in fact -- the ability to repeatedly edit is a pleasant surprise.
+"""]]
diff --git a/doc/sync.mdwn b/doc/sync.mdwn
index 057dcb355..540e64545 100644
--- a/doc/sync.mdwn
+++ b/doc/sync.mdwn
@@ -22,7 +22,7 @@ fetches from each remote, and merges in any changes that have been made
 to the remotes too. Finally, it updates `synced/master` to reflect the new
 state of `master`, and pushes it out to each of the remotes.
 
-This way, changes propigate around between repositories as `git annex sync`
+This way, changes propagate around between repositories as `git annex sync`
 is run on each of them. Every repository does not need to be able to talk
 to every other repository; as long as the graph of repositories is
 connected, and `git annex sync` is run from time to time on each, a given