Wouldn't it make sense to offer

git annex pull

which would basically do

git pull
git annex get

and

git annex push

which would do

git annex commit .
git annex put # (the proposed "send to default annex" command)
git commit -a -m "$HOST $(date +%F-%H-%M-%S)" # or similar
git push

Resulting in commands that are totally analogous to git push & pull: Sync all data from/to a remote.

Update:

This is useful:

git config [--global] alias.annex-push '!git pull && git annex add . && git annex copy . --to $REMOTE --fast --quiet && git commit -a -m "$HOST $(date +%F--%H-%M-%S-%Z)" && git push'

Maybe, otoh, part of the point of git-annex is that the data may be too large to pull down all of it.

I find mr useful as a policy layer over top of git-annex, so "mr update" can pull down appropriate quantities of data from appropriate locations.

Comment by http://joey.kitenet.net/ Tue Apr 5 18:05:00 2011

No-so-subtle sarcasm taken and acknowledged :)

Arguably, git-annex should know about any local limits and not have them implemented via mr from the outside. I guess my concern boils down to having git-annex do the right thing all by itself with minimal user interaction. And while I really do appreciate the flexibility of chaining commands, I am a firm believer in exposing the common use cases as easily as possible.

And yes, I am fully aware that not all annexes are created equal. Point in case, I would never use git annex pull on my laptop, but I would git annex push extensively.

Comments on this page are closed.