Re: syncing non-git trees with git-annex

2011-12-14 Thread Richard Hartmann 
I would use

  find -name \*.avi -exec git annex add {} \;

but other than that, this seems fine. Depending on your level of OCD,
it might make sense to throw away the initial repo once your data is
clean and import everything in a clean one. That's what I do.


Richard

PS: There are various tools for finding duplicates, but git-annex
gives you this functionality for free, so..
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: syncing non-git trees with git-annex

2011-12-14 Thread Adam Spiers 
On Wed, Dec 14, 2011 at 12:53 PM, Richard Hartmann
richih.mailingl...@gmail.com wrote:
 I would use

  find -name \*.avi -exec git annex add {} \;

That's substantially less performant, because it forks a whole new
tree of git / git-annex processes per file.

If we're getting picky, we should also worry about spaces in
filenames:

  find -name \*.avi -print0 | xargs -0 git annex add

but it was only an example, and to be honest, I didn't even use the
xargs variant myself; I used zsh's recursive globbing:

  git annex add **/*.avi

but I thought that might confuse non-zsh users so I replaced it with
xargs in the example :-)

 but other than that, this seems fine.

Great, thanks!

 Depending on your level of OCD,
 it might make sense to throw away the initial repo once your data is
 clean and import everything in a clean one. That's what I do.

Interesting - any particular reason for doing that?

 PS: There are various tools for finding duplicates, but git-annex
 gives you this functionality for free, so..

Yes, this one is particularly good:

  http://sourceforge.net/projects/fastdup/

but using git-annex facilitates it in a much more distributed fashion.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: syncing non-git trees with git-annex

2011-12-14 Thread Richard Hartmann 
On Wed, Dec 14, 2011 at 14:15, Adam Spiers vcs-h...@adamspiers.org wrote:

 That's substantially less performant, because it forks a whole new
 tree of git / git-annex processes per file.

True.


 Interesting - any particular reason for doing that?

Mainly that I will keep my repos for as long as I can reasonably plan
ahead and that I will _know_ that there is crud which I can not
remove, ever. I.e. just cleanliness.
Similar to how some people like to make their beds, even though it's
more work and actually less healthy to do so.


Richard
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home