Recent comments posted to this site:

comment 1 cc9caa5dd22dd67e5c1d22d697096dd2
[[!comment Error: unsupported page format txt]]
Wed Jan 8 16:45:55 2014
comment 5 8789fc27466714faa5a3a7a6b8ec6e5d
[[!comment Error: unsupported page format txt]]
Wed Jan 8 16:45:39 2014

The AUR package you reference is woefully out of date. I have updated the standalone variant so it might be worth using that until the maintainer catches up.

yaourt -Sy git-annex-standalone
Comment by http://alerque.com/ Sat Dec 28 22:04:24 2013

@Dav what kind of url does the upstream remote have? Perhaps it would be sufficient to make sync skip trying to push to git:// and http[s]:// remotes. Both are unlikely to accept pushes and in the cases where they do accept pushes it would be fine to need a manual git push.

Anyway, you can already configure which remotes get synced with. From the man page:

       remote.<name>.annex-sync
              If set to false, prevents  git-annex  sync  (and  the  git-annex
              assistant) from syncing with this remote.

So git config remote.upstream.annex-sync=false

Comment by http://joeyh.name/ Thu Dec 12 17:54:55 2013
@joeyh - ok, good to know. So as long as I realize I need to sync with my hard drives before deleting, it should work fine as a backup solution. Sweet!

@Zellyn, what you describe does not sound unreasonable. But it's hard to say if it's a backup. For example, if you delete a file from the archive folder, and that happened to be the only copy of the file, it's gone.

It's definitely possible to use git-annex in backup-like ways, but what I want to discourage is users thinking that just putting files into git-annex means that they have a backup. Proper backups need to be designed, and tested. It helps to use software that is explicitly designed as a backup solution. git-annex is more about file distribution, and some archiving, than backups.

Comment by http://joeyh.name/ Wed Dec 11 15:40:35 2013

I'd like to understand the "not a backup system" point better. My current plan was to use git annex assistant to save my annex folder onto two hard drives, one at home and one at work. Step two is to move most big stuff into .../archive/... folders, and step three is to add an annex folder on my wife's laptop, so we can use the hard drives to back up everything.

Does that sound unreasonable?

Just in case you haven't considered such a scenario - maybe you have suggestions for how to collaborate more effectively with git annex (and avoid warning messages):

I'm trying to teach beginning scientist programmers (mostly graduate students), and a common scenario is to fork some scientific code. I'd like forking on github to be mundane, and not trigger warnings, and generally have as little for folks to explicitly keep track of as possible (this seems to be a common concern we share, which leads you to prefer syncing to all remotes without the option to configure the default behavior!).

However, I am currently working with students on forking and fixing up scientific code where the upstream maintainer doesn't want to allow pushes upstream, except via pull request. So, part of our approach is to set up some common shared datasets in git annex (and these just end up in our fork). If we have an "upstream" remote, git annex will try to sync with it, and report an error.

So - that's why I'd like to be able to configure the deactivation of syncing to a defined branch (e.g., "upstream"). However, if you have other suggestions to smooth the workflow, I would also like to hear those!

I feel that syncing with all remotes by default is the right thing for git annex sync to do.
Comment by http://joeyh.name/ Tue Nov 26 20:08:33 2013

By default, git annex sync will sync to all remotes, unless you specify a remote. So, I have to specify, e.g., git annex sync origin. I can simplify this with aliases, I suppose, but I do a lot of teaching non-programmer scientists... so it'd be nice to be able to configure this (so beginning users don't have to keep track of as many things).

Is there (or will there be) a way to do this?

Comments on this page are closed.