responses, bug I noticed

This commit is contained in:
Joey Hess 2017-08-15 14:42:22 -04:00
parent 19a784df03
commit 73d04d5565
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 41 additions and 0 deletions

View file

@ -0,0 +1,5 @@
It's possible for a key to contain whitespace in its name. This breaks the
external special remote protocol, which uses whitespace to separate the key
parameter from subsequent parameters.
I think that this only causes problems for WORM keys. --[[Joey]]

View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="joey"
subject="""re: export "each revision""""
date="2017-08-15T18:13:38Z"
content="""
That sounds much more like a regular remote with `git annex copy --all`.
This entire design is preducated on exporting a single treeish. If you want
to make a single treeish containing all versions of every file ...
"""]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="joey"
subject="""re: Git History"""
date="2017-08-15T18:16:31Z"
content="""
That is entirely out of scope. You're looking for a way to store a git
*repository* someplace like S3. Such things exist already, and are not
git-annex and I'm not going to replicate them as part of this feature.
"""]]

View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="joey"
subject="""re: comments on protocol"""
date="2017-08-15T18:18:14Z"
content="""
In `TRANSFEREXPORT STORE|RETRIEVE Key File Name`, it should always
be possible for the File to not contain spaces in its name. But it could be
rather painful for git-annex to avoid spaces in some cases (would need to
link or copy the annexed file content). So well spotted.
Hmm, it's actually possible for a Key to contain spaces as well,
at least with the WORM backend.
[[external_special_remote_protocol_broken_by_key_with_spaces]]
The protocol `VERSION` is picked by the special remote, it's not
negotiated.
"""]]