mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2015-08-26 07:24:01 -07:00
commit 762a462304
7 changed files with 118 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

23
doc/design/external_special_remote_protocol/comment_17_8dc7bbf485c9385a4b506e8b8fa934fe._comment Normal file
View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
subject="WHEREIS -- is it better to just report failure to avoid duplicates?"
date="2015-08-26T14:22:49Z"
content="""
I wonder how should I utilize this new API (WHEREIS) in my case: it seems just to lead to duplication of whereis information in my case of a special remote to support extracting of content from archives. If I make it to reply with the same url (which is not \"public\" per se, i.e. can't be used by annex directly) I just get it duplicated:
$> git annex whereis simple.txt
whereis simple.txt (1 copy)
82025765-5cac-4571-91ed-637620ec6fc7 -- [annexed-archives]
annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
ok
if I \"explain\" it a bit, also somewhat duplicate:
annexed-archives: file a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20 within archive SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz
annexed-archives: dl+archive:SHA256E-s173--5df2eeab61ea7d6479533d4e6b07c6bcfae46e040cad8cb1fc579f9f18c90790.tar.gz/a/d/%20%22%27%3Ba%26b%26cd%20%60%7C%20
But if I just reply with \"WHEREIS-FAILURE\" it becomes more sensible (no duplicates), but I feel that then better documentation for this feature get adjusted to describe
that it is only to complement information already known to annex, and not really to \"provide any information about ways to access the content of a key stored in it\". Or have I missed the point? ;)
"""]]

9
doc/forum/Searching_metadata_and_file_content__63__/comment_4_b8fbd129664c9680cd77f89185974741._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="jean.jordaan@4bb3bd508a9eb0a4bab5d1b587dadd2b6c4a7edc"
nickname="jean.jordaan"
subject="recoll: there's a Unity Lens for it"
date="2015-08-26T13:04:12Z"
content="""
I see there is an Ubuntu Unity search lens for recoll: http://www.webupd8.org/2012/03/recoll-lens-full-text-search-unity-lens.html
It should be possible to integrate git-annex metadata with that ..
"""]]

9
doc/forum/removing_remote.log_information_completely.mdwn Normal file
View file

@ -0,0 +1,9 @@
in [[forum/remote-specific_meta-data/]], we have learned how to insert our own remote-specific metadata, in remote.log. now, we need a way to remove that data. for some reason, injecting commits in the `git-annex` branch doesn't quite work, because other assistants will overwrite that merge thanks to the [[git-union-merge]] driver.
so far, i have found that it *can* be possible to work around this problem by repeatedly doing commits on the git-annex branch and running `git-annex sync` by hand after. it stumbles and flips around for a while, but eventually does it. it does create nice sparkles in gitk:
![a tangled mess in gitk](http://i.imgur.com/PD4ne50.png)]
What is the proper way of removing entries from `remote.log`? How about propagating changes to the `synced/git-annex` branch? I can generate commits on `git-annex` using the git-annex index, and on the `git-annex` branch. But how should those changes be propagated to other branches?
Thanks! --[[anarcat]]

59
doc/special_remotes/glacier/comment_12_a097d78d15e103c10f67e237c852b222._comment Normal file
View file

@ -0,0 +1,59 @@
[[!comment format=mdwn
username="git-annex,branchable.com@1fa4b21c7ece2d61d4730de8e83329049126cedc"
nickname="git-annex,branchable.com"
subject="Glacier-cli works, thanks, some encode / decode error now..."
date="2015-08-26T08:30:53Z"
content="""
Hi Joey,
Thanks for the hand, it started uploading once I had manually created the vault but then borked with:
fozz@cobol:~/Store/family_pictures $ git annex --verbose copy 201/2011/05/07/P1010004.RW2 --to familypictures-glacier
copy 201/2011/05/07/P1010004.RW2 (gpg) (checking familypictures-glacier...) (to familypictures-glacier...)
81% 4.0MB/s 0sTraceback (most recent call last):
File \"/home/fozz/.vendor/bin/glacier\", line 730, in <module>
App().main()
File \"/home/fozz/.vendor/bin/glacier\", line 716, in main
self.args.func()
File \"/home/fozz/.vendor/bin/glacier\", line 498, in archive_upload
file_obj=self.args.file, description=name)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/vault.py\", line 177, in create_archive_from_file
writer.write(data)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 219, in write
self.partitioner.write(data)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 61, in write
self._send_part()
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 75, in _send_part
self.send_fn(part)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 222, in _upload_part
self.uploader.upload_part(self.next_part_index, part_data)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/writer.py\", line 129, in upload_part
content_range, part_data)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 1279, in upload_part
response_headers=response_headers)
File \"/usr/local/lib/python2.7/dist-packages/boto/glacier/layer1.py\", line 114, in make_request
data=data)
File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 1071, in make_request
retry_handler=retry_handler)
File \"/usr/local/lib/python2.7/dist-packages/boto/connection.py\", line 943, in _mexe
request.body, request.headers)
File \"/usr/lib/python2.7/httplib.py\", line 979, in request
self._send_request(method, url, body, headers)
File \"/usr/lib/python2.7/httplib.py\", line 1013, in _send_request
self.endheaders(body)
File \"/usr/lib/python2.7/httplib.py\", line 975, in endheaders
self._send_output(message_body)
File \"/usr/lib/python2.7/httplib.py\", line 833, in _send_output
msg += message_body
UnicodeDecodeError: 'ascii' codec can't decode byte 0x8c in position 0: ordinal not in range(128)
gpg: [stdout]: write error: Broken pipe
gpg: DBG: deflate: iobuf_write failed
gpg: build_packet failed: file write error
gpg: [stdout]: write error: Broken pipe
gpg: iobuf_flush failed on close: file write error
gpg: symmetric encryption of `[stdin]' failed: file write error
git-annex: fd:17: hPutBuf: resource vanished (Broken pipe)
failed
git-annex: copy: 1 failed
"""]]

3
doc/todo/autoenable__61__true_for_special_remotes.mdwn Normal file
View file

@ -0,0 +1,3 @@
Just passing along from https://github.com/datalad/datalad/issues/77#issuecomment-134688459
joey: I do think there could be a use case for configuring a special remote with autoenable=true and have git-annex init try to enable all such remotes.

9
doc/todo/autoenable__61__true_for_special_remotes/comment_1_c4926ed92263c78bafbee3862f12bab4._comment Normal file
View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="http://joeyh.name/"
subject="comment 1"
date="2015-08-25T18:25:44Z"
content="""
There are going to be many configurations where auto-enable of a special remote fails. Ie, when creds are needed. While some of these could be detected and skipped, I sort of like the simplicity of having it try to enable everything.
Maybe a command is also needed to autoenable remotes after the first git-annex init? Since it's actually ok to re-run git-annex init in an initalized repo, I suppose it could just be run again.
"""]]

9
doc/trust.mdwn
View file

@ -20,7 +20,7 @@ There is still some trust involved here. A semitrusted repository is
depended on to retain a copy of the file content; possibly the only
[[copy|copies]].
(Being semitrusted is the default. The `git annex semitrust` command
(Being semitrusted is the default. The [[git-annex-semitrust]] command
restores a repository to this default, when it has been overridden.
The `--semitrust` option can temporarily restore a repository to this
default.)
@ -34,7 +34,7 @@ This is a good choice for eg, portable drives that could get lost. Or,
if a disk is known to be dying, you can set it to untrusted and let
`git annex fsck` warn about data that needs to be copied off it.
To configure a repository as untrusted, use the `git annex untrust`
To configure a repository as untrusted, use the [[git-annex-untrust]]
command.
## trusted
@ -49,7 +49,7 @@ access a remote you trust. Or to use `--trust` to specify a repository to
trust temporarily.
To configure a repository as fully and permanently trusted,
use the `git annex trust` command.
use the [[git-annex-trust]] command.
## dead
@ -57,3 +57,6 @@ This is used to indicate that you have no trust that the repository
exists at all. It's appropriate to use when a drive has been lost,
or a directory irretrievably deleted. It will make git-annex avoid
even showing the repository as a place where data might still reside.
To configure a repository as dead and lost, use the [[git-annex-dead]]
command.