summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2013-12-04 13:14:34 -0400
committerGravatar Joey Hess <joey@kitenet.net>2013-12-04 13:14:34 -0400
commit9f32f5a8c8265574b21491dcfd5565270530b505 (patch)
treea9fbeb40fc8a9cc28a24c4683345295fb2029ab9
parent7edfb1651619db820470d2ea5ddde8fef57df67d (diff)
parentb2c5be989676b621d36585158799aa31b5604e02 (diff)
Merge branch 'master' of ssh://git-annex.branchable.com
-rw-r--r--doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment26
-rw-r--r--doc/bugs/git_annex_lock_dangerous.mdwn17
2 files changed, 43 insertions, 0 deletions
diff --git a/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment
new file mode 100644
index 000000000..b5b499669
--- /dev/null
+++ b/doc/bugs/Assistant_has_created_155_semitrusted_repositories/comment_14_b958da97a69091d283918e0d5a658da5._comment
@@ -0,0 +1,26 @@
+[[!comment format=mdwn
+ username="https://www.google.com/accounts/o8/id?id=AItOawnNqLKszWk9EoD4CDCqNXJRIklKFBCN1Ao"
+ nickname="maurizio"
+ subject="comment 14"
+ date="2013-12-04T08:47:15Z"
+ content="""
+I followed the procedure you suggested, please see email for how to transfer it to you. There are several points I would like to note:
+
+1. In the cloned repository created as you suggest above, the output of ```git annex status``` does not contain all the weird things that appear in the original repository (although it contains other stuff, see 3)
+2. In the original repository (~/datadir/Annex), the output of ```git annex status``` still contains the 155 nonrepositories, plus some other stuff (see 3)
+3. In the meantime, I created (always with the webapp) another annex for private stuff (~/private/Annex) on the same set of machines. Although I chose to \"keep repositories separated\", the few files that I put for testing into the new ~/private/Annex have appeared as broken symlinks in the work annex ~/datadir/Annex. The transfer repositories used for the work and private annexes are different and are not even hosted on the same machines. The jabber account on the contrary is the same for all annexes.
+4. In the webapp (client1) in ~/private/Annex, only the correct repositories appear.
+5. In the webapp (client1) in ~/datadir/Annex the correct repositories appear, plus the private repository of client 2 and twice the transfer repository of the ~/private/Annex
+6. ```git annex status``` on client1 in ~/datadir/Annex shows the repositories of ~/private/Annex in addition to the 155 nonrepositories and its own repositories
+7. Because of 3), you will find at the end of the logs some new stuff that is in principle not related to the original bug report.
+
+In the end the situation is now the following:
+
+* 3 annexes (~/Annex for initial testing, ~/datadir/Annex for work, ~/private/Annex for private stuff), all created via webapp and handled by the assistant
+* files which were added on client 1 into ~/private/Annex also appear as broken links in ~/datadir/Annex on client 1 but nowhere in client 2
+* files which were added on client 2 into ~/private/Annex also appear as broken links in ~/datadir/Annex on client 1 and in client 2
+* The first created annex still seems to work as expected
+
+I am sorry that the situation is that messy. Is there a way to separate these repositories that have somehow become entangled?
+
+"""]]
diff --git a/doc/bugs/git_annex_lock_dangerous.mdwn b/doc/bugs/git_annex_lock_dangerous.mdwn
new file mode 100644
index 000000000..f7b204784
--- /dev/null
+++ b/doc/bugs/git_annex_lock_dangerous.mdwn
@@ -0,0 +1,17 @@
+### Please describe the problem.
+
+Git annex lock discards data without --force; this is misleading from the name.
+
+### What steps will reproduce the problem?
+
+ git annex unlock something.txt
+ kwrite something.txt # edit
+ git annex lock something.txt # lock is the opposite of unlock, right?
+
+Oops, just lost my changes!
+
+If you want my opinion, `git annex lock` should either require `-f` to throw away data or should be renamed (e.g. to `revert` or `checkout`).
+
+### What version of git-annex are you using? On what operating system?
+
+git version 1.8.1.2, git-annex version: 4.20130815, Kubuntu 13.04