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 2019-01-07 16:36:53 -04:00
commit 5500cbbc30
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
8 changed files with 126 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

17
doc/bugs/__34__error__58___invalid_object__34____44___after_add__59___cannot_commit/comment_19_bdd9e29413f4407207efa01283ad68ad._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="anarcat"
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
subject="bump"
date="2019-01-05T23:06:05Z"
content="""
same here: scary error message, easy fix (`rm .git/annex/index.lck`):
(recording state in git...)
error: invalid object 100644 81c85a0001f059e769034c34d4f739376ecd9429 for '000/53b/SHA256E-s1346--41101bacc557f53ceec3a7fd401a3f6a53c0dfe649ac7fe2812208e4d0384a13.RAF.xmp.log'
fatal: git-write-tree: error building trees
git-annex: failed to read sha from git write-tree
CallStack (from HasCallStack):
error, called at ./Git/Sha.hs:18:15 in main:Git.Sha
Unfortunately, this is a very large repo and I can't really reproduce now that I removed the lockfile. Do note there was an out of disk space condition earlier on that drive, but that was resolved before starting the git-annex operations. -- [[anarcat]]
"""]]

8
doc/bugs/cannot_talk_with_nextcloud_server/comment_3_f4163aeca38202707721299471f40e0b._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="anarcat"
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
subject="thanks!"
date="2019-01-06T04:12:03Z"
content="""
I confirm this is fixed - thanks! This makes exporttree, the webdav endpoint, and so many more things finally make sense to me! :)
"""]]

2
doc/bugs/sync_does_not_drop_local_content_present_in_exporttree_remote.mdwn
View file

@ -10,4 +10,4 @@ drop local unwanted content that's got only 1 copy on another remote.
It forgot to include the local copy as a currently present copy, throwing
off the numcopies counting. --[[Joey]]
Both [fixed|done]] --[[Joey]]
Both [[fixed|done]] --[[Joey]]

59
doc/bugs/webdav_remote_fails_on_pound_signs.mdwn Normal file
View file

@ -0,0 +1,59 @@
### Please describe the problem.
When doing an `export` to a WebDAV remote, git-annex chokes on directory that have the `#` character in it, presumably because it has special meaning in HTTP.
### What steps will reproduce the problem?
Roughly, setup a WebDAV remote:
WEBDAV_USERNAME=anarcat WEBDAV_PASSWORD=REDACTED git annex initremote webdav type=webdav url=https://example.net/nextcloud/remote.php/webdav/Photos/ encryption=none exporttree=yes
Create a directory with a pound sign in it, and export it:
mkdir -p pictures/foo#1 ; touch pictures/foo#1/test; git annex add pictures ; git commit -myolo
git annex export master:pictures --to webdav
### What version of git-annex are you using? On what operating system?
7.20181211-2 on Debian buster, from Debian packages.
### Please provide any additional information below.
Here's part of the output from the of the original export command:
[...]
export lib3.net documentation/photo/IMG_0636.JPG
ok
export lib3.net documentation/radio/Antenna #1/20101107_002.jpg
failed
[...]
Trying to export again retries only those but still fails:
$ git annex export master:pictures --to webdav
export lib3.net documentation/radio/Antenna #1/20101107_002.jpg
failed
[...]
I have since then renamed the evil directory to remove the pound sign. But then export tries to rename it and still fails:
$ git annex export master:pictures --to lib3.net
rename lib3.net documentation/radio/Antenna #1/20101107_005.jpg -> .git-annex-tmp-content-SHA256E-s53186--07c80575cc0fa2b902fd0828f4b4ce0b12af7be94721a1e50134ec78bb67bc2e.jpg
rename failed; deleting instead
[...]
... and it then proceeds to upload the renamed files correctly:
[...]
export lib3.net documentation/radio/antenna-1/20101107_002.jpg
ok
[...]
The log doesn't show it, but delete also fails, as a new export run will try to rename the old files again, and fail.
It wouldn't be so bad if git-annex would fail to upload to a webdav repo and just force the user to use sane filenames. The problem is it doesn't recover when the user does fix its shit... ;)
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
I'm running out of ideas here, to be honest. I've certainly had a lot of "luck" running git-annex before, but as others have said, "there's no such thing as luck" and the reason this whole thing works at all is because you work so hard on making it. So: thanks again! --[[anarcat]]

17
doc/forum/How_to_view_progress_of_in-progress_upload__63__.mdwn Normal file
View file

@ -0,0 +1,17 @@
Hello,
I have a large (3.3 GB) file uploading to a Backblaze B2 remote ... when I first issued the `git annex copy --to` command, it showed a nice progress bar. However, it didn't finish on the first attempt (probably due to system hibernation or something).
At first I couldn't get it to resume; I used `git annex whereis` to confirm that it wasn't in the remote (and confirmed manually), then I tried to reissue the `git annex copy` command to resume, but I got an error: copy failed: "transfer already in progress, or unable to take transfer lock".
I'm not sure how, but I got it to resume ... I think it was `git annex copy --failed --to=(remote)` ... I know that it resumed because I can see the network traffic, confirmed in nethogs that it is coming from git-annex-remote-b2, and issuing `git annex info` reports the file is uploading under `transfers in progress`.
What I'm wondering, is how can I get information on the progress of the upload, how much it's done and has left, etc? Or even a progress bar, since the initial `copy` command gave a nice progress bar?
I've been searching the documentation, man pages, and web, but haven't found anything so far ... please forgive me and let me know if I missed this somewhere.
Thank you.
PS: I love git annex; it's taken me a while to grok it and start using it usefully (despite my being already a somewhat experienced git user); but the steep-ish learning curve is worth it, for a file management system with flexible, distributed backends, that I can have control over, and with versioning. Thank you very much for creating and sharing and continuing to work on it.
-- aaronw

8
doc/forum/Move_history/comment_10_da64814a7dfc2322200130a17bb79923._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Chymera"
avatar="http://cdn.libravatar.org/avatar/555d585d6d78c68894ac90fd1e984309"
subject="comment 10"
date="2019-01-06T01:25:10Z"
content="""
it did indeed look like data from an unintended and interrupted \"git annex add *\", deleted it and now the space issue has resolved. Thank you.
"""]]

8
doc/forum/largefiles__58___fail-on-unspecified_mode__63__.mdwn Normal file
View file

@ -0,0 +1,8 @@
The imminent move of to v7 of my shared repositories (eg. family photo collection) offers a chance to simplify the workflow from differentiating between `git annex` commands and `git` commands for participants who have a hard time keeping them apart using `largefiles`. In practice, `largefiles` would be configured to always annex JPEG files, various raw formats and video data, but to never annex data like SVG files (typically collages), .pto files (Hugin's panorama files) or READMEs.
I don't trust the above list to be comprehensive, and want to avoid errors in both directions (needlessly annexed files I'd actually want under regular version control, and worse yet, huge files in the hard-to-edit git history).
Is there (or could there be added) a way I could set files to a "I don't know" state of largefiles (and make that the default for everything not explicitly configured), such that `git add` would rather err out than making the wrong decision?
Thanks<br />
[[chrysn]]

8
doc/git-annex-add/comment_4_48e3f9438721b9696897bc6e5a41f4ac._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="timeless-ventricle"
avatar="http://cdn.libravatar.org/avatar/0b220fa4c0b59e883f360979ee745d63"
subject="comment 4"
date="2019-01-06T12:24:49Z"
content="""
@joey I'm obviously missing something here, why would a shorter way to write that only be useful for direct mode? I don't understand what the connection is between direct mode and wanting to specify whether this is a \"regular git\" file or an annexed file (except that direct mode is not supported in v7)? I thought it was considered supported to have a mix of both large binary files and text files? Even if some text files are large, I think I want to add them as files whose content is tracked by git, so I think I want to choose 'by hand' -- is that not really supported / considered a bad idea for some reason?
"""]]