Recent comments posted to this site:

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?

Comment by scottgorlin Tue Oct 18 21:17:40 2016

@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.

Comment by joey Mon Oct 17 19:33:29 2016

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.

Comment by joey Mon Oct 17 19:24:35 2016

Adding this to .gitattributes:

*.xmp annex.largefiles=nothing

Causes git-annex add to behave as expected. Questions about git annex undo behavior remain.

Comment by https://launchpad.net/~stephane-gourichon-lpad Fri Oct 14 07:23:51 2016

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 emptied newdir 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 emptied newdir 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.

Comment by https://launchpad.net/~stephane-gourichon-lpad Fri Oct 14 07:02:42 2016
Right, this is what happens when you don't even read the article you have commented on.
Comment by barthalion Tue Oct 11 21:00:53 2016

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.

Comment by fiatjaf Tue Oct 11 13:35:07 2016

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.

Comment by https://launchpad.net/~stephane-gourichon-lpad Mon Oct 10 06:43:49 2016
Is it possible to specify compression level to be used for 'bup split'?
Comment by barthalion Sat Oct 8 18:31:00 2016
wzhd, you can do 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).
Comment by http://christian.amsuess.com/chrysn Fri Oct 7 09:11:55 2016