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

This commit is contained in:
Joey Hess 2019-01-21 12:34:18 -04:00
commit 9753824ec8
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
9 changed files with 64 additions and 3 deletions

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="zsolt"
avatar="http://cdn.libravatar.org/avatar/ef26f34d5d953cf139c58e5dc4b5fe73"
subject="works!"
date="2019-01-18T22:40:39Z"
content="""
thanks very much Joey!
"""]]

View file

@ -0,0 +1,8 @@
### Please describe the problem.
I had "fun" today doing some initial configuration of a laptop with Windows 10. I remembered that I need to install Git first, so did that first, 64 bit since that is what is the laptop is. Then when got to install git-annex remembered that it is recommended to install 32bit built of Git instead. Oh well, I left [a comment]() and proceeded hoping to resolve rsync issue if/when arises.
The problem came upon reboot when I got "Windows Script Host" error "Can not find script file C:\Program Files (x86)\Git\cmd\git-annex-autostart.vbs". Oh well, indeed -- there is no " (x86)\Git" and as described above it was "on purpose". So it feels that some "recommended" value is hard-coded somewhere?
P.S. I really hope that someone eventually takes time to make git-annex become available for Windows from conda-forge.
[[!meta author=yoh]]

View file

@ -11,8 +11,8 @@ understand how to update its working tree.
## deprecated
Direct mode is deprecated! Intead, git-annex v7 repositories can simply
have files that are unlocked and thus can be directly accessed and
Direct mode is deprecated! Instead, git-annex v7 repositories can simply
have files that are [[unlocked|tips/unlocked files]] and thus can be directly accessed and
modified. See [[upgrades]] for details about the transition to v7
repositories.

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="andrew"
avatar="http://cdn.libravatar.org/avatar/acc0ece1eedf07dd9631e7d7d343c435"
subject="comment 4"
date="2019-01-20T21:14:03Z"
content="""
Great, glad to hear this setup might work for you. Also, I also forgot to mention another drawback with `encryption=pubkey` is that you can't easily add add a key for a newly added developer later on, if you want to add a new developer key after you have uploaded files to s3 you will have to drop all the files, add the new key to git-annex, make sure all your devs do a `git-annex sync` to get the new set of public keys to use for encryption, then re-upload all the files to s3.
"""]]

View file

@ -1,6 +1,6 @@
[Box.com](http://box.com/) is a file storage service.
** WebDAV access to box.com will be disabled as of February 1, 2019. At that point, the method described on this page will no longer work. See [this announcement](https://community.box.com/t5/Box-Product-News/Deprecation-WebDAV-Support/ba-p/55684) for further details. **
** WebDAV access to box.com will be deprecated on January 31, 2019. At that point, the method described on this page will no longer work. See [this announcement](https://community.box.com/t5/Box-Product-News/Deprecation-WebDAV-Support/ba-p/55684) for further details. **
git-annex can use Box as a [[special remote|special_remotes]].
Recent versions of git-annex make this very easy to set up

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
nickname="lykos"
avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
subject="comment 2"
date="2019-01-21T11:57:07Z"
content="""
Import tree won't help here. Actually I've got the same problem on one of my machines. I'm currently using a script that imports a bunch of files and moves them to the remote, then imports some more files and so on. It's quite cumbersome, to be honest. So yes, I'd appreciate `git annex import --to <remote>` as well. (Same with `git annex move --from remote-a --to remote-b` actually.)
"""]]

View file

@ -0,0 +1,9 @@
[[!comment format=mdwn
username="lykos@d125a37d89b1cfac20829f12911656c40cb70018"
nickname="lykos"
avatar="http://cdn.libravatar.org/avatar/085df7b04d3408ba23c19f9c49be9ea2"
subject="comment 1"
date="2019-01-21T11:40:07Z"
content="""
Great idea! I like it that this way all remotes benefit speed wise while only the ones which actually use these commands will have to be updated. That's a huge plus over something like PREPARE-LOCAL.
"""]]

View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="Ilya_Shlyakhter"
avatar="http://cdn.libravatar.org/avatar/1647044369aa7747829c38b9dcc84df0"
subject="comment 1"
date="2019-01-18T20:57:36Z"
content="""
Great, thanks! Maybe, can make a new release soon?
"""]]

View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="yarikoptic"
avatar="http://cdn.libravatar.org/avatar/f11e9c84cb18d26a1748c33b48c924b4"
subject="May be it is time?"
date="2019-01-20T15:32:38Z"
content="""
> ... Postponed until old versions of git-annex-shell are less common
I find installation on windows unnecessarily complicated with current demand of using x86 git. Not that it is impossible but it makes it more elaborate, even for old timers.
Would be nice if it was streamlined more. I even wondered if there is a way to provide (additional) bundles which would come with git itself. This way it could be just the git-annex installer to install all needed for working with git-annex (instead of this multistep process)
"""]]