From bb8286d6c5b12be958a4bcb3832dd3bf15f0aaeb Mon Sep 17 00:00:00 2001 From: "http://christian.amsuess.com/chrysn" Date: Sun, 11 Nov 2012 01:15:41 +0000 Subject: [PATCH 1/6] Added a comment: further tracking --- ...comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment 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 0000000000..96dbc6a2e2 --- /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 , let's see what the developer says. +"""]] From e1139c9a0133149e4b84a03549e9de6db01cc7e8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=98yvind=20A=2E=20Holm?= Date: Sun, 11 Nov 2012 02:44:32 +0100 Subject: [PATCH 2/6] doc/sync.mdwn: Typo fix 5c945f18-2ba1-11e2-8d66-00c0a8deee11 --- doc/sync.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/sync.mdwn b/doc/sync.mdwn index 057dcb355e..540e645459 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 From 25e626e1ebc596664b12a12b0a6659798be71cdd Mon Sep 17 00:00:00 2001 From: "http://meep.pl/" Date: Sun, 11 Nov 2012 09:00:01 +0000 Subject: [PATCH 3/6] Added a comment: xmlns --- ...comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment 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 0000000000..7ee62eea7f --- /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\". +"""]] From 2a4367e0ee59f7b8934528c6cff8e1373e9b3791 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Sun, 11 Nov 2012 16:06:42 +0000 Subject: [PATCH 4/6] Added a comment --- ...comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment 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 0000000000..f17fc56345 --- /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. +"""]] From e8e6730eecd28eec5811a432e1013da0a28a6d28 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmraN_ldJplGunVGmnjjLN6jL9s9TrVMGE" Date: Sun, 11 Nov 2012 20:14:44 +0000 Subject: [PATCH 5/6] Added a comment: How to convert bare repositories to non-bare --- ..._148e1da70d37d311634a0309a4ff8dcd._comment | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment diff --git a/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment b/doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment new file mode 100644 index 0000000000..c1ba9f2f4a --- /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 + + +"""]] From 215313f2586aa170e22462596f42327bf9343045 Mon Sep 17 00:00:00 2001 From: "http://peter-simons.myopenid.com/" Date: Sun, 11 Nov 2012 21:03:55 +0000 Subject: [PATCH 6/6] Add a request to support earlier versions of the network library --- ...___2.4.0.1_is_not_in_Haskell_Platform_2012.4.0.0.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/network___62____61___2.4.0.1_is_not_in_Haskell_Platform_2012.4.0.0.mdwn 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 0000000000..98a8932363 --- /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.