bug triaging and tagging

3 files changed, 67 insertions, 0 deletions

diff --git a/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn b/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
new file mode 100644
index 000000000..a7b30ded5
--- /dev/null
+++ b/doc/todo/assistant_cannot_set_up_remote_repo_via_an_ssh_alias_or_an_ip_address.mdwn
@@ -0,0 +1,48 @@
+What steps will reproduce the problem?
+
+Using the assistant, create an SSH remote.  Try to use an alias as the name
+of the remote (e.g. I have a server which I have aliased to "homeworld" in
+my .ssh/config.  When I'm at home, that is an alias for 192.168.1.253.
+When I'm not at home, I edit .ssh/config so that "homeworld" becomes an
+alias for a hostname at no-ip.com.)  Despite the fact that "homeworld" is a
+viable ssh target because of the alias, the assistant doesn't recognize it
+as a valid host to ssh to.
+
+I had trouble with an ip address the first time I tried it but just tried
+it again and it worked fine, so please disregard that part of the title of
+this bug report.
+
+
+What is the expected output? What do you see instead?
+
+expected output = move to the "create a repository -- rsync or regular" page.
+observed output = "cannot resolve host name"
+
+
+What version of git-annex are you using? On what operating system?
+
+ Version: 3.20130102 OS X Lion
+
+
+Please provide any additional information below.
+
+I realize this is kind of a power user whine.  Using an ssh alias which
+does not correspond to an actual resolvable hostname (and cannot, because
+it's supposed to be a layer of indirection over the hostname) is not an
+everyday problem for an average user.
+
+> The assistant tries to resolve the hostname explicitly
+> to catch user's typos, and also expands it to a FQDN, to make
+> it more likely to be able to reach the host when roaming to other
+> networks.
+> 
+> Also, the assistant sets up it *own* .ssh/config hostname alias,
+> in order to make it use the special ssh key that it generates for the host.
+> So that is not compatable with using a ssh host alias you've set up.
+> Even if it knew about your alias, it would set up a new hostname alias, and
+> whatever machinery you have to update the alias would not work.
+>  
+> You can, of course, add git remotes using any ssh alias you like, by
+> hand, and restart the assistant and it will use them. --[[Joey]]
+
+[[!tag /design/assistant]]
diff --git a/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn b/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn
new file mode 100644
index 000000000..361585a78
--- /dev/null
+++ b/doc/todo/automatic_merge_of_synced_branches_upon___34__git_annex_sync__34__.mdwn
@@ -0,0 +1,16 @@
+When maintaining several replica of the same git-annex repo "git annex sync" is quite handy.
+But it would be even handier if "git annex sync" would also perform automatic "git merge synced/*" actions on all remotes.
+
+Clearly, this is beneficial when the user wants to keep all working copies synchronized.
+This is likely the case in git annex assistant like scenarios. And it's always the case in my day to day scenarios :-)
+I'm not sure about other use cases that I've hard time imagining...
+
+As just discussed on IRC (#vcs-home/OFTC), this could be implemented in various ways:
+
+1) By doing ssh on each remote and running the appropriate "git merge ..." commands there.
+   The drawback of this is that quite often it won't be permitted to ssh on the remote and run arbitrary commands there.
+
+2) Having a default post-receive hook, created at the time of "git annex init" that automatically does the merges when contacted by other remotes as a consequence of "git annex sync".
+
+
+Thanks for git-annex!
diff --git a/doc/todo/optinally_transfer_file_unencryptedly.mdwn b/doc/todo/optinally_transfer_file_unencryptedly.mdwn
new file mode 100644
index 000000000..d622fcdab
--- /dev/null
+++ b/doc/todo/optinally_transfer_file_unencryptedly.mdwn
@@ -0,0 +1,3 @@
+I have a git-annex repository on a NSLU 2, and transfers are much slower over ssh compared to unencrypted transfers (no wonder at that CPU speed). For the files that I am transferring, no encryption would be necessary. Unfortunately, ssh in Debian does not support "-c none" to disable encryption.
+
+It would be nice if git-annex would have a way of conveniently transferring files in another way than SSH. I’m not sure what a good way would be – maybe launching a one-shot HTTP-server on the sending end? Haskell libraries for that would be available... Of course it is not always the case that the host reachable with "ssh foo" is also reachable via TCP at "foo:1234"... And there are surely more problem. But still, it would be nice :-)