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 2018-03-12 17:33:37 -04:00
commit ad13b56c86
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
12 changed files with 132 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/bugs/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_1_57844bc289adacc6a53162cd224e6df3._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 1"
date="2018-03-09T18:55:51Z"
content="""
May be would be of help: here datalad-archives spits out TRANSFER-SUCCESSes really fast since it takes it little time to just copy a little file... so it feels to me that issue is in some race condition within git-annex. If I add 100ms delay before returning TRANSFER-SUCCESS from the special remote - number of failures goes down to 0-2 instead of 5ish. With 200ms delay seems to get no failures whatsoever.
"""]]

8
doc/bugs/get_-JX__58____transfer_already_in_progress_..._for_some_files/comment_2_ea5d3efc56b70de03a5b0b5e908bf11f._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="comment 2"
date="2018-03-09T19:00:27Z"
content="""
FWIW: I was wrong with the statement that # of failures goes upto the X in -JX -- just got 13 (when no delay) with -J5.
"""]]

30
doc/design/p2p_protocol/comment_1_367bebae5b84408c7592b5fcca993c1e._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="anarcat"
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
subject="late to the party"
date="2018-03-12T13:50:33Z"
content="""
eh... i look elsewhere for a week and you design another line
protocol! ;) so I guess it's too late to do anything to change this,
but I wanted to share that similar efforts are being done over the
backup software world, in particular in [restic][],
which is working with the [rclone][] project to implement an abstract
get/pull mechanism to store blobs, a lot like what git-annex needs to
be doing.
they wrote this using a binary protocol for speed (it's basically RPC
at this point) and I encouraged them to at least use a standard one
(they use protobufs + HTTP2 AKA gRPC, iirc, and it works over
stdin/out). you might find the [full thread][] interesting... it
would be great if git-annex would support this natively instead of
rolling its own protocol, because it would mean it could talk with
other services like rclone or restic servers out of the box, without
*those* endpoints having to implement yet another custom protocol.
but yeah, i'm way too late it seems. figured you might find it
interesting anyways... congrats on the performance improvements!
[restic]: https://restic.net
[rclone]: https://rclone.org/
[full thread]: https://github.com/restic/restic/issues/1561
"""]]

2
doc/devblog/day_489__zooming.mdwn
View file

@ -8,7 +8,7 @@ This looks really nice!
I've completed the P2P protocol with git-annex-shell. It turned out just as
fast and good as I'd hoped.
[[accellerate_ssh_remotes_with_git-annex-shell_mass_protocol]] has the
[[todo/accellerate_ssh_remotes_with_git-annex-shell_mass_protocol]] has the
benchmark details.
Even transferring of large files speeds up somewhat;

12
doc/devblog/day_489__zooming/comment_1_d840f371f1d22b0ee8f3c8df25ebe3d3._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="anarcat"
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
subject="progress bars?"
date="2018-03-12T13:44:50Z"
content="""
how do progress bars work in this new design? we had those for free with rsync before (i assume?), do we still have them now?
how about [[todo/wishlist__58___global_progress_status]]? is that more feasible now?
thanks!
"""]]

21
doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_2_54ba7672150ee32df4d2d92390a960c1._comment Normal file
View file

@ -0,0 +1,21 @@
[[!comment format=mdwn
username="andrew"
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
subject="comment 2"
date="2018-03-10T18:33:22Z"
content="""
Thanks for the positive feedback!
>Please do file todo requests if there are interface improvements that git-annex can offer to query for the data you need.
Will do. I think I have most of the queries I need right now. I really wanted to show nice, meaningful icons for folders; I ended up showing some measure of the number of copies of all files contained within folders. This is something I decided to cache in a database since, to my knowledge, neither git nor git-annex tracks folders directly. I don't think it would make sense to cache folder level queries in git-annex anytime soon?
>But I do wonder if it would make sense for the git-annex.app to bundle git-annex-turtle, so users don't need that extra step.
Great! Yes, that sounds like an excellent idea! Yes, as you mentioned git-annex-turtle.app is ~30mb with all the icon assets. I believe this is because the icons are uncompressed PDFs exported from Adobe Illustrator, oops. I'll see if I can compress them and get the .app size down. Currently, zipping git-annex-turtle.app brings down the size to ~8mb.
Thanks,
—Andrew
"""]]

10
doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_3_107d0a3c9de6880d0ee164a651d2c20e._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="anarcat"
avatar="http://cdn.libravatar.org/avatar/4ad594c1e13211c1ad9edb81ce5110b7"
subject="beautiful"
date="2018-03-12T13:52:53Z"
content="""
wow, that is absolutely gorgeous. i wish we had the same in linux! it would make git-annex so much simpler to use... but i don't know if contrib plugins can add graphic stuff like that in file manager displays in nautilus/etc?
seems like we're clearly lagging behind when I look at the finder... can't believe we still don't have a proper file manager in linux yet... --[[anarcat]]
"""]]

10
doc/forum/released_finder_integration_for_macOS_called_git-annex-turtle/comment_4_ddb6d671ddd28ba79efce74e41eab7e1._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="andrew"
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
subject="comment 4"
date="2018-03-12T19:24:56Z"
content="""
Thanks [anarcat](http://git-annex.branchable.com/users/anarcat/)!
[RabbitVCS](http://rabbitvcs.org/) provides Nautilus 3 icons for git, that might be a reasonable starting point for enhanced git-annex icons on Linux. Also, [nautilus-git](https://github.com/bil-elmoussaoui/nautilus-git) is minimal and quite pretty. I don't know what flavor of file manager they were using when they took their screenshots.
"""]]

13
doc/install/ArchLinux/comment_11_0d51aaebe5929b03cba38156a97bf3cc._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="douglass.doug@f332d3f2822cae5f75accdf82fdab4a8f565e1f9"
nickname="douglass.doug"
avatar="http://cdn.libravatar.org/avatar/51567f932ee16ed200c339f44986d173"
subject="git-annex-bin package?"
date="2018-03-09T20:59:02Z"
content="""
Seems the git-annex-bin package is no longer in AUR.
@caleb any interesting in resurrecting the old git-annex-bin package?
It would be a welcome option for users that have no other haskell-based packages installed vs. the community/git-annex package that now depends on ghc and *many* separate haskell packages. Reply or ping me, I can assist.
"""]]

3
doc/special_remotes.mdwn
View file

@ -33,8 +33,7 @@ for using git-annex with various services:
* [Amazon Cloud drive](https://github.com/DanielDent/git-annex-remote-rclone)
* [[tips/Internet_Archive_via_S3]]
* [[Box.com|tips/using_box.com_as_a_special_remote]]
* [Google Drive](https://github.com/Lykos153/git-annex-remote-gdrive)
* [[Google Drive (old)|tips/googledriveannex]]
* [Google Drive](https://github.com/Lykos153/git-annex-remote-googledrive)
* [[Google Cloud Storage|tips/using_Google_Cloud_Storage]]
* [[Mega.co.nz|tips/megaannex]]
* [[SkyDrive|tips/skydriveannex]]

14
doc/todo/smudge/comment_11_ace695aa9d6c5d888b91a2eebb19f97b._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="davicastro"
avatar="http://cdn.libravatar.org/avatar/4e708663cf4d5b9e8cfea74caf4307fc"
subject="What are the drawbacks of repo v6?"
date="2018-03-12T19:00:36Z"
content="""
Hi. I read the post http://git-annex.branchable.com/tips/unlocked_files/, and got into this post through the comment to check the limitations of repo v6.
I read through this post, but I still don't grasp the drawbacks of repo v6.
I like the idea of mixed mode repositories with locked and unlocked co-existing. And I need repo v6 for that right?
I also like the annex.largefiles to control what is annex what is normal git files.
With these two combined feature I can configure my project and let users without too much burden on controlling what is annex, what is not, and what are locked or unlocked.
I want to use repo v6, but what are the drawbacks on adopting it? Is it in terms of git could be bugged? Or the smudge filters could be bugged?
Sorry for not being able to grasp this from the current post. I appreciate any help. Thanks.
"""]]

4
doc/users/andrew.mdwn Normal file
View file

@ -0,0 +1,4 @@
Andrew Ringler <a href="mailto:public@andrewringler.com">public@andrewringler.com</a>
<br><https://andrewringler.com/>
[git-annex-turtle](https://github.com/andrewringler/git-annex-turtle) —Apple Finder integration for git-annex on macOS, including custom badge icons, contextual menus and a Menubar icon