mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Merge remote-tracking branch 'branchable/master'

Browse source
This commit is contained in:
Joey Hess 2011-04-07 22:05:03 -04:00
commit dfc1bfcc76
5 changed files with 61 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/bugs/fat_support/comment_3_df3b943bc1081a8f3f7434ae0c8e061e._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="fmarier"
subject="comment 3"
date="2011-04-05T10:00:21Z"
content="""
Thanks for the reply @joey.
While it would certainly be possible for a bare repo to exist on my iRiver, the problem is that the music player uses the filesystem to organize files into directories like \"Artist/Album/Track.ogg\". So replacing that with \"..../xx/yy/Track.ogg\" would make it fairly difficult to browse my music collection and select the album/track I want to listen to :)
So unless I have the files physically organized like the symlinks, then it's probably not going to work very for that particular workflow. Smudge filters are interesting though. In the meantime, I'll look into rsyncing from another box which has the right filesystem layout onto my iRiver directly.
"""]]

10
doc/design/encryption/comment_4_8f3ba3e504b058791fc6e6f9c38154cf._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joey.kitenet.net/"
nickname="joey"
subject="comment 4"
date="2011-04-07T19:59:30Z"
content="""
@Richard the easy way to deal with that scenario is to set up a remote that work can access, and only put in it files work should be able to see. Needing to specify which key a file should be encrypted to when putting it in a remote that supported multiple keys would add another level of complexity which that avoids.
Of course, the right approach is probably to have a separate repository for work. If you don't trust it with seeing file contents, you probably also don't trust it with the contents of your git repository.
"""]]

11
doc/forum/Problems_with_large_numbers_of_files/comment_6_4551274288383c9cc27cbf85b122d307._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="http://joey.kitenet.net/"
nickname="joey"
subject="comment 6"
date="2011-04-07T18:09:13Z"
content="""
I've committed the queue flush improvements, so it will buffer up to 10240 git actions, and then flush the queue.
There may be other memory leaks at scale (besides the two I mentioned earlier), but this seems promising. I'm well into running `git annex add` on a half million files and it's using 18 mb ram and has flushed the queue several times. This run
will fail due to running out of inodes for the log files, not due to memory. :)
"""]]

10
doc/forum/wishlist:_git_annex_put_--_same_as_get__44___but_for_defaults/comment_3_2082f4d708a584a1403cc1d4d005fb56._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U"
nickname="Richard"
subject="comment 1"
date="2011-04-04T10:28:01Z"
content="""
Going one step further, a --min-copy could put all files so that numcopies is satisfied. --all could push to all available ones.
To take everything another step further, if it was possible to group remotes, one could act on the groups. \"all\" would be an obvious choice for a group that always exists, everything else would be set up by the user.
"""]]

19
doc/forum/wishlist:_git_annex_status.mdwn Normal file
View file

@ -0,0 +1,19 @@
Ideally, it would look similar to this. And yes, I put "put" in there ;)
non-annex % git annex status
git annex status: error: not a git annex repository
annex % git annex status
annex object storage version: A
annex backend engine: {WORM,SHA512,...}
Estimated local annex size: B MiB
Estimated total annex size: C MiB
Files without file size information in local annex: D
Files without file size information in total annex: E
Last fsck: datetime
Last git pull: datetime - $annex_name
Last git push: datetime - $annex_name
Last git annex get: datetime - $annex_name
Last git annex put: datetime - $annex_name
annex %
Datetime could be ISO's YYYY-MM-DDThh:mm:ss or, personal preference, YYYY-MM-DD--hh-mm-ss. I prefer the latter as it's DNS-, tag- and filename-safe which is why I am using it for everything. In a perfect world, ISO would standardize YYYY-MM-DD-T-hh-mm-ss-Z[-SSSSSSSS][--$timezone], but meh.