Recent comments posted to this site:
Just find some related / complimentary work for this. It is a bunch of ranger functions that wrap git-annex commands inside ranger:
:annex_add → git annex add + git commit -a
:annex_get → git annex get
:annex_drop → git annex drop
:annex_copy <remote> → git annex copy --to=<remote>
:annex_sync → git annex sync --fast --quiet
The code is at https://github.com/matze/ranger-annex
More information on this blog post.
Hello,
Following https://git-annex.branchable.com/install/fromsource/ "building from source on Debian" succeeds on Xubuntu 16.04 but fails on Debian 7.11.
First observed on recent commit ade6ab4
(the one that was used on Xubuntu 16.04) then failed the same way with most recent commit f244d94
and for tag debian/6.20160719-1
.
Haskell context was installed on the machine specifically to build git-annex, so there should not be any extraneous package.
Surprisingly, "make" and "cabal" output rather different messages.
make
if [ "cabal" = ./Setup ]; then ghc --make Setup; fi
if [ "cabal" = stack ]; then \
cabal build ; \
else \
cabal configure --ghc-options=""; \
fi
Warning: git-annex.cabal: Ignoring unknown section type: custom-setup
Resolving dependencies...
Warning: git-annex.cabal: Ignoring unknown section type: custom-setup
Utility/Exception.hs:29:18:
Could not find module `Control.Monad.Catch'
Perhaps you meant
Control.Monad.CatchIO (from MonadCatchIO-mtl-0.3.0.4)
Control.Monad.Base (from transformers-base-0.4.1)
Control.Monad.Cont (from mtl-2.1.1)
Use -v to see a list of the files searched for.
make: *** [Build/SysConfig.hs] Erreur 1
cabal install
Warning: git-annex.cabal: Ignoring unknown section type: custom-setup
Resolving dependencies...
cabal: Could not resolve dependencies:
next goal: git-annex (user goal)
rejecting: git-annex-6.20160923, 6.20160907, 6.20160808 (global constraint
requires ==6.20160619)
trying: git-annex-6.20160619
trying: base-4.5.0.0/installed-40b... (dependency of git-annex-6.20160619)
trying: git-annex-6.20160619:+concurrentoutput
next goal: concurrent-output (dependency of
git-annex-6.20160619:+concurrentoutput)
rejecting: concurrent-output-1.7.7, 1.7.6, 1.7.5, 1.7.4, 1.7.3, 1.7.2, 1.7.1,
1.7.0, 1.6.1, 1.6.0 (conflict: base==4.5.0.0/installed-40b...,
concurrent-output => base(>=4.6))
rejecting: concurrent-output-1.5.0, 1.4.0, 1.3.0, 1.2.0, 1.1.0, 1.0.1, 1.0.0
(conflict: git-annex-6.20160619:concurrentoutput => concurrent-output(>=1.6))
Any hint? When succeeding the pair of machines will be my first remote ssh-based repo. I need a recent enough build for mixed content repository that would automatically put some types of files in regular git and some other types in annex. Thanks.
git annex addurl file:///full/path/to/file.torrent
. this has the downside of denoting a local file that may vanish or not be present at the same location in another checkout, but then again, same goes for http uris. (i'd rather like the torrent file or at least the info part thereof present in git or git-annex; adding the torrent with addurl --raw
and then using its file://
url at least gives all the data needed to use the torrent again).
I find out that I need to add the following lines to the gitolite.rc in the server side.
'git-annex-shell ua'
The signal repository works with gitolite as expected. However, the mirroring feature is not working for slaves. When I do
git annex copy --to origin
The master server store the annex file correctly. The file managed by annex is not syncing to the slave mirrors at all.
git-annex will probe to detect if the filesystem does not support FIFOs and
disables annex.sshcaching
in that case. It's done so since 2013. So I would
be surprised if NFS had any problems with annex.sshcaching.
git config annex.pidlock true
will make git-annex avoid FCNTL locking,
and so work on filesystems that don't support that. It should also
avoid the ".nfs" files.
It's not enabled by default on NFS because I don't currently have a good way to probe if a given directory is on NFS.
Also, annex.pidlock makes git-annex significantly slower and less safe. But if you're using NFS, speed and safety must have already been de-prioritized.
Seriously, my main advice for using git-annex on NFS is: Don't. Make local clones of repositories and use git-annex to distribute the files around. Unless your institution forces you to use a networked filesystem to access gobs of disk space, and you need to have more files present in a repository than will fit locally.
@kartynnik, that's a bug: sync uses conflicting names for deep branches
Please file bugs there and not as comments here, it's too easy to lose track of a comment deep in a thread.
In the meantime, the stack.yaml has been updated to use lts-7.0, which includes concurrent-output-1.7.7, so that should solve that.