Support for git-annex

[ka7]

Hi,

beets is cool stuff, I just want to share my point-of-view:

i have stored my music in a git-annex [1] library. ( but they are also exported via smb ) (i do same for my videos, iso's, some backups... )

Now, the standard beets "rename" ( or "fix track names" ) seems not work in this scenario properly, so in git-annex a "renaming" is more a "git mv A B " than a "mv A B"

For the moment i work with "git-annex unlock" and "git-annex lock" afterwards.

...or maybe there is a more clever way to do so ? .ka7 1] https://git-annex.branchable.com/walkthrough/

[sampsyo]

Very cool idea. This would certainly be useful to have.

I think it should be possible to get most of the way there using a plugin. We have plugin events for most of the relevant file operations, including move, so a plugin could just simply notify git-annex when this happens. Worth looking into...

[multikatt]

@ka7 isn't git-annex's direct mode what you want? That's what i've been using together with beets for a while now. That doesn't require unlocking and locking.

[Profpatsch]

I’m trying to set up my music library with git annex atm, and the same issue popped up. In the meantime, some things have changed, though:

With v6 of git annex repositories we can now globally unlock files in a much more efficient manner (direct mode is deprecated). There is also git annex adjust --unlock, which creates a branch where all files are unlocked. The checkout is linear the the amount of files (or possible even the filesize) though, so this isn’t viable since we need all files to be writable for beets to work in a sane way.

As far as I see it, the best way is to run git annex unlock once on the whole library, commit and then use the normal git commands after that, as described on the wiki page I linked earlier.

[jackwilsdon]

On a semi-related note, we now have the hook plugin (since v1.3.18) which allows you to run commands based on certain beets events (i.e. you could use cli_exit to sync files on exit).

[Profpatsch]

Workflow:

# upgrade to v6 (not yet done automatically, as of 2016-06)
git annex upgrade
git annex unlock
# takes time linear to the filesize the first time
git add -A
# takes around the same time as the previous command :(
git commit -m "unlocked repository"
beet <something>
git add -A
git commit -m "my changes"

[anarcat]

in #2616 i describe a possible plugin for doing exactly this, which would unlock files before writing them, basically. seems like a simple enough plugin too.

i guess the hook config would be:

hook:
  hooks:
    - event: write
      command git annex unlock \"{path}\"
    - event: after_write
      command: git annex add \"{item.path}\"

i wonder if this would cover the item_moved, item_copied, item_hardlinked, item_linked, item_removed and item_imported cases as well, or if we need specific hooks for all of those.

one should also generally call git annex commit after such changes, but that should happen once per batch, say at cli_exit but then we don't want to always commit and only commit the paths we changed. therefore I wonder if the hook module is such a good match: a custom module could keep track of what happened and so on...

[TobiX]

It seems beets already does split commands into "proper" arguments, so this confg worked for me:

hook:
  hooks:
    - event: write
      command: "git annex unlock {path}"
    - event: after_write
      command: "git annex add {item.path}"