summaryrefslogtreecommitdiff
path: root/doc/todo
diff options
context:
space:
mode:
Diffstat (limited to 'doc/todo')
-rw-r--r--doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn14
-rw-r--r--doc/todo/direct_mode_undo.mdwn2
-rw-r--r--doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment14
-rw-r--r--doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment17
4 files changed, 47 insertions, 0 deletions
diff --git a/doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn b/doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn
new file mode 100644
index 000000000..146b0622b
--- /dev/null
+++ b/doc/todo/Display_fingerprint_to_WebApps_GPG___34__create_encrypted_new_repo__34__.mdwn
@@ -0,0 +1,14 @@
+ I'm using git-annex 5.20150205-gbf9058a and just used the WebApp to create a new remote SSH repo, and thought I'd try the encrypted option.
+
+It give me three GPG keys to choose from (all valid keys) but only displayed the email addresses which were all identical so I couldn't tell which was which.
+
+I then clicked the first key selection button, hoping it would display more info but it seemed to start doing things immediately. It requested the GPG passphrase which I cancelled but it was still doing things, and worse it wasn't clear what state the repo was in (encrypted or not), so I deleted it and started again (it's fine now).
+
+The passphrase dialog box does display the key fingerprint, but it's then too late to alter the key selection.
+
+Request: Could the WebApp always display the fingerprint after the email address?
+
+Some clarity on what happens when you cancel would be nice too.
+
+Thanks
+Giovanni
diff --git a/doc/todo/direct_mode_undo.mdwn b/doc/todo/direct_mode_undo.mdwn
index 926222d97..82c2e4ab8 100644
--- a/doc/todo/direct_mode_undo.mdwn
+++ b/doc/todo/direct_mode_undo.mdwn
@@ -84,3 +84,5 @@ that touched files in that directory, and undo the changes to those files.
Also, --depth could make undo look for an older commit than the most
recent one to affect the specified file.
+
+See [[direct_mode]] for documentation about this feature.
diff --git a/doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment b/doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment
new file mode 100644
index 000000000..35e1b90b0
--- /dev/null
+++ b/doc/todo/direct_mode_undo/comment_1_bd7e9f152805a57cce97bef64e4891dd._comment
@@ -0,0 +1,14 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="comment 1"
+ date="2015-02-15T05:46:01Z"
+ content="""
+> This way, if a file has a staged change, it gets committed, and then that commit is reverted, resulting in another commit. Which a later run of undo can in turn revert. If it didn't commit, the history about the staged change that was reverted would be lost.
+
+so far, my experience with this is that unstaged changes get dropped and the change that gets undoed is the last committed change. In other words, if i have:
+
+ $ git annex status
+ M file
+
+`git annex undo` is going to drop that modification and `git revert HEAD`. but maybe i got confused, in which care some of the documentation i just did in [[direct mode]] needs to be corrected. --[[anarcat]]
+"""]]
diff --git a/doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment b/doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment
new file mode 100644
index 000000000..1f300b881
--- /dev/null
+++ b/doc/todo/direct_mode_undo/comment_2_b826160420e0f343aadc5353e50aed2b._comment
@@ -0,0 +1,17 @@
+[[!comment format=mdwn
+ username="https://id.koumbit.net/anarcat"
+ subject="sigh... nevermind"
+ date="2015-02-15T05:52:02Z"
+ content="""
+seems like i was wrong. i could have sworn i saw a committed file get unstaged. what i saw was:
+
+ $ git annex status
+ M file
+ $ git annex undo file
+ $ git annex status
+ ? file
+
+the thing is: the file was *removed* in a previous version, so i thought this was what it reverted to. i'm unsure as to why the file was marked as missing there - i ended up reverting from a backup (from another remote, by hand). after trying to reproduce this, i failed, so there may have been some PEBKAC in action again.
+
+this feature is so useful though, thanks for this. --[[anarcat]]
+"""]]