Added a comment

doc/todo/add_prefix_option_to_export/comment_3_c76aa611a2b389b9d7a0512a733c0d03._comment

@@ -0,0 +1,23 @@
+[[!comment format=mdwn
+ username="andrew"
+ avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
+ subject="comment 3"
+ date="2018-11-20T17:45:34Z"
+ content="""
+OK. Excellent, yes `git mktree` sounds promising, although I might still need an additional option to `export` to achieve my goals (maybe `--append-only` see last paragraph). Here is more detail on my use case:
+
+I am looking to add a `Share` feature to [git-annex-turtle](https://github.com/andrewringler/git-annex-turtle). Often, I have one file, or a few files that I wish to share with people. Typically I will upload these to google drive and then create a public share link from the entire folder they are in, then share that with people over email. With `git-annex-turtle` I would like a user to be able to right-click on a file, a multiple-file selection or a folder, choose `Share` and then have these files shared somewhere publicly, then report back to the user the public URL of this share (via their clipboard or a dialog).
+
+I don't know what remote types would be desirable for `git-annex-turtle` users, but I was hoping that I could find a solution that could work for any remote type that already supports public file downloads and the `exporttree` option. Probably rsync, s3 and google drive would be a good first start. s3 and google drive already support public downloads and a savy user could certainly make their rsync remote support public downloads as well.
+
+The issue with *“initializing one remote per export directory”* is that I would like to minimize effort for my `git-annex-turtle` users. I think it is reasonable to ask them to setup one public remote one time, then they can re-use that remote anytime they want to share something new. But I wouldn't want to have to ask them to create a new remote everytime they click the `Share` button. It is certainly plausible that I could automate this process, but then I would need to investigate storing security credentials and the various authentication mechanism for various supported remotes and write code to auto-generate new remotes of various types on the fly.
+
+Using `git mktree` seems very promising since I could pass it an arbitrary set of 1 or more files or folders that are already present in `git`, create a new tree then share that tree using the export command. One problem with this is that it becomes tricky when I want to share another tree, without deleting previously exported trees (right?). I think, if I could keep track of all trees previously shared I could create a new tree containing all of the old trees and the new tree. But, I don't want to do this, because `git-annex-turtle` is designed to store no critical file or content information that can't be automatically recreated from the git repositories themselves.
+
+I am wondering if adding an option like `--append-only` to the `export` command would resolve this issue? This option would disable the entire merge process, never deleting content from a remote, only ever adding. I could then create new trees using `git mktree` anytime I want to do a new share and just do the export of that new tree with the `--append-only` option and not have to worry about `git annex` trying to merge changes and delete previously exported trees? Or perhaps this isn't any easier than a `--prefix` option since the `export` command needs to locally keep track of what it exported? Perhaps there could be a new command instead of `export`? Some kind of command that supports any remote that already supports the `exporttree` option? Perhaps something like `git annex copy-tree treeish --to the-public-remote` would copy a tree to a remote using something similar to the `export` mechanism but would never attempt to do any merging and would never keep track of what was uploaded. Or perhaps the `--append-only` option to `export` could behave similarly, never keeping track locally of what was uploaded.
+
+
+
+
+
+"""]]