Recent comments posted to this site:
@stephane-gourichon, Control.Monad.Catch is in the haskell exceptions package, which is a dependency of git-annex. I don't know why it is failing to find it on your system.
You appear to be in some variety of cabal hell; you probably need to delete your ~/.cabal and ~/.ghc and start over.
Also, Debian 7.11 is quite old; to follow the "building from source on Debian" you need Debian unstable, testing, or sometimes stable (doesn't work currently); not oldstable.
git annex undo
undoes the last change that was committed to the file.
If the file has staged changes, git annex undo
first commits those
changes (to avoid losing data) and then undoes that commit.
The reason that git annex undo
deleted the files from your working tree
is that the previous commit did not have those files in it, and it undid
to the state at that commit.
So, you will never lose the content of a file by running git annex undo
.
If git annex undo
deletes a file, you can always get it back by
checking out a previous version of the branch. Or even by running git
annex undo
a second time, to undo the undo.
Adding this to .gitattributes
:
*.xmp annex.largefiles=nothing
Causes git-annex add
to behave as expected. Questions about git annex undo
behavior remain.
Hello,
Context
Thank you for git-annex. I'm progressing in learning how to use it. Seems to work as intended with only annexed files.
I actually need mixed content repository and like the idea of annex.largefiles
deciding which files go into the annex.
While experimenting with mixed content repository, I had git-annex-undo
destroy information twice. Or perhaps I did something wrong?
What happened
Here's my .gitattributes
``` .NEF annex.largefiles=anything .JPG annex.largefiles=anything *.jpg annex.largefiles=anything
```
I had a directory (say, newdir
) with some jpg and some other files, not known by git or git-annex so far.
Based on https://git-annex.branchable.com/tips/largefiles/ I expected both git add
and git annex add
to add NEF JPG jpg to the annex, and other files as regular git files.
In case of problem, I expected git annex undo
to revert state to the one just before the last command (which is: full of my regular files, not symlinks or empty).
git add newdir
added them all as regular files, not partly in the annex as expected. Surprised, I wanted to undo and try another command.git annex undo
emptiednewdir
completely. Wow! Fortunately these were copies, else they would have been gone forever! To be fair I have not checked at that point if files had been copied in annex, which as only copy would still be a mess because file names would have been lost anyway.
I used git reset <hash>
to revert state git-style, checked with git status
that state was indeed back to pre-add (newdir empty, not known to git), then copied the files again from their source.
git annex add newdir
added them all as annexed files, replacing with links, not partly as regular files as expected.git annex undo
emptiednewdir
completely. I expected my regular files back in place.
I had the intended result by using git add
on regular files and git annex add
to add files to be annexed. As if .gitattributes
were absent.
git-annex compiled on Debian unstable as of 2016-10-13 from git source, commit 3135d35094aa5453ef7a5f12762e00e0139a6dbb.
Questions
- Have I explained situation clearly?
- Did
git annex add
behave as intended by you? Wasn't it supposed to automatically decide which files go to the annex? - Did
git annex undo
behave as intended by you? Wasn't it supposed to revert working directory to the state just before the wrong "add"? - Have I used
.gitattributes
,add
commands correctly?
Thank you.
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).
Are the synced/* branches necessary for a bare repo? Since there is no working directory, can't sync operate directly on the top level branches of choice, and avoid 'branch pollution'? Is it implemented this way just to simplify the code, or ...?
Also wondering if there is a practical difference between a bare repo and an rsync repo (other than storing the metadata, of course) - they both use rsync for transfer, no? Any speed/overhead/other differences to consider when choosing?
For my use case pertaining to question 2 I am using a local ARM NAS which works with the binary (plus S3 or gdrive remotes etc), but I figure why not spin up a private gitlab repo with metadata and no content since I want an off-site backup of the metadata anyways. Does a bare repo on a nas add anything here, vs an rsync remote? Perhaps just rsync is even better to avoid overhead on a tiny/slow NAS?