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

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2013-12-16 16:33:17 -04:00
commit 081cfba131
8 changed files with 83 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

12
doc/bugs/Resource_exhausted/comment_11_24ad3a76a25a787ac59e2c5270709e72._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 11"
date="2013-12-16T17:20:34Z"
content="""
I now understand the problem described in comment 6, where once it started failing, it would leak one file descriptor per failure.
I think that failure mode was fixed by accident in the changes in [[!commit 2fd63f3cfac705f0a18f4bcbe0489ce8ea1800d7]].
This doesn't explain what would open so many files to get it into that failure mode, however.
"""]]

13
doc/bugs/direct_mode_sync_should_avoid_git_commit/comment_2_4e23201d1d1d549f72eec75987601a73._comment Normal file
View file

@ -0,0 +1,13 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 2"
date="2013-12-16T17:14:06Z"
content="""
It seems that `ls-files --modified` runs the same code path that commit did to see if the file is changed, which here is a cheap
stat, and on your system mmaps and downloads it all.
I cannot see a good way to avoid using `ls-files --modified`.
I think it would be better to fix git.
"""]]

10
doc/bugs/fatal:_git_ls-files:_cannot_generate_relative_filenames_containing___39__..__39__/comment_3_d252f39ddb9c9c14784c85a8b850a4ec._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 3"
date="2013-12-16T16:27:28Z"
content="""
You can leave off the -c core.bare=false, if your git does not support it.
That is an exceptionally old version of git. I'm sure it's the problem, so you should upgrade.
"""]]

10
doc/bugs/fatal:_git_ls-files:_cannot_generate_relative_filenames_containing___39__..__39__/comment_4_eb07c84dc0b15b68c99d0ef4144f82f5._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawnWaZGX4m5Oic-vvIKUJHZLrY5W1G7mtQ4"
nickname="Andrew"
subject="comment 4"
date="2013-12-16T20:16:26Z"
content="""
Built and installed Git 1.8.5 from source and the problem went away.
Thanks!
"""]]

8
doc/bugs/git-annex:_WebDAV_failed_to_write_file:_TlsNotSupported:_user_error/comment_3_62ff37a8429cfb3577d4250c701811d0._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawleVyKk2kQsB_HgEdS7w1s0BmgRGy1aay0"
nickname="Milan"
subject="comment 3"
date="2013-12-16T16:41:08Z"
content="""
Thanks, after the update it works.
"""]]

10
doc/design/external_special_remote_protocol/comment_1_5baff75d278394a8818c348fb4f13b8a._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmicVKRM8vJX4wPuAwlLEoS2cjmFXQkjkE"
nickname="Thomas"
subject="not useful for "plain directory" special remote?"
date="2013-12-16T20:10:16Z"
content="""
It says: \"Note that the File should not influence the filename used on the remote. The filename used should be derived from the Key.\"
Thus this interface might not be useful to implement [[todo/New special remote suggeston - clean directory]]? The clean directory special remote would just do that: save $key content on the remote under the filename $file.
"""]]

10
doc/forum/Windows_S3_host_issue/comment_3_1715557daa15b9e9e17b4850141e62af._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 3"
date="2013-12-16T17:07:17Z"
content="""
Looking at this again, you forgot to tell it the name of the remote, so it took the first parameter (host=\"objects.dreamhost.com\" ) as the name. The rest probably follows from that mistake.
use `git annex initremote mys3 host=...`
"""]]

10
doc/tips/what_to_do_when_you_lose_a_repository/comment_4_679eb9be0bfb9d48a2b96383c4816f62._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="209.250.56.87"
subject="comment 4"
date="2013-12-16T17:04:44Z"
content="""
I wouldn't recommend running `git annex forget --drop-dead` right after losing a drive. You might find the drive again, or get the dead drive to work again. Even if you know you'll never find it, you may want to query git-annex to find files that were only located on that drive, and deal with them, etc.
But if you're worried about that information in the git-annex branch cluttering up the git repository, you keep in mind that `git annex forget` will let you remove it at some point in the future.
"""]]