[[!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.





"""]]
