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

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

Browse source
This commit is contained in:
Joey Hess 2013-04-06 15:36:46 -04:00
commit 54d7637b3a
11 changed files with 128 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
doc/bugs/Direct_mode_keeps_re-checksuming_duplicated_files/comment_3_6a6d22d218f036c9977072973ed99aa8._comment Normal file
View file

@ -0,0 +1,11 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawm5iosFbL2By7UFeViqkc6v-hoAtqILeDA"
nickname="Laszlo"
subject="identical filename"
date="2013-04-06T09:09:17Z"
content="""
Same happens, with identical filename+content just in a different subdirectory.
annex/a.txt
annex/back/a.txt
"""]]

14
doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work.mdwn Normal file
View file

@ -0,0 +1,14 @@
What steps will reproduce the problem?
1. Create a Repository
2. Add a Remote Server
What is the expected output? What do you see instead?
The option "Use a git repository on the server" is marked as not available
What version of git-annex are you using? On what operating system?
Version: 4.20130405 but on Webapp ist shows: Version: 4.20130324
Linux 64bit
Please provide any additional information below.
git and git-annex are available on the Remote Server

12
doc/bugs/Use_a_git_repository_on_the_server_don__39__t_work/comment_1_2143f0540fdcd7efeb25b5a3b54fe0fd._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 1"
date="2013-04-06T16:38:46Z"
content="""
Well, it works here. It checks that all of `git`, `rsync`, and `git-annex` are in the path on the remote server using `which`.
I think the most likely reason would be if you've installed git-annex on the remote server but not in the PATH. If you're using the standalone tarball, for example, it's \"installed\", but it has no way to find it.
Or, you could have installed from cabal, which puts it in ~/.cabal/bin or ~/bin or something like that, and perhaps you configured your shell to put that directory in the PATH, but you did it in a way that only works for login shells. If you set the PATH in `~/.bashrc`, for example, that would not work for a noninteractive shell.
"""]]

24
doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add.mdwn Normal file
View file

@ -0,0 +1,24 @@
What steps will reproduce the problem?
Unable to reproduce as it seems to happen randomly, to very few files (4/250).
What is the expected output? What do you see instead?
I expect to see the assistant warn if it attempts to add a file which fails to add to the annex.
Instead, I see no output from the assistant, but lines like this in the log.
daemon.log.2:add Indie Game Stand/Deadly 30/Deadly30_MAC.zip (checksum...) failed
daemon.log.2:add Indie Game Stand/Wyv and Keep/xnafx40_redist.msi (checksum...) failed
daemon.log.2:add Indie Game Stand/Blueberry Garden/Blueberry_Garden_1.1.zip (checksum...) failed
daemon.log.2:add Indie Game Stand/Flatspace Bundle/fsmusicpack3setup.exe (checksum...) failed
There is no reason given for the failure in the log file. The assistant also never tries to add them again in normal running (but did add them when it was started again after a reboot).
What version of git-annex are you using? On what operating system?
git-annex version: 4.20130314
OS: Arch Linux
Please provide any additional information below.
The assistant in this case is being used as nothing more than a way for me to see which files have been added (--verbose, --foreground and --debug with 'watch' outputs nothing..). No remotes or anything like that.

10
doc/bugs/assistant_does_not_warn_on_files_it_failed_to_add/comment_1_13b2f93b7d09c8fd6c22829a0dc6428b._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 1"
date="2013-04-06T16:34:00Z"
content="""
The assistant runs a daily sanity checker job which will clean up files like these. (`git annex watch` does not, however).
I think the main reason add could fail is if a file gets modified while it's in the process of being added. It could retry right away, although it needs to do it in a way that does not loop if the file continually fails to be added.
"""]]

8
doc/bugs/git-annex_add_should_repack_as_it_goes/comment_3_ff8b589fbcf25c98abd1c58830074650._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 3"
date="2013-04-06T06:32:56Z"
content="""
More testing shows that only the first git commit is slow. A second commit will be fast whether or not `git-repack` has been run in between.
"""]]

8
doc/design/assistant/blog/day_230__Mom/comment_1_696bba2246c8a9e6ce4aed3071bcc96c._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://edheil.wordpress.com/"
ip="68.35.120.66"
subject="comment 1"
date="2013-04-05T23:50:14Z"
content="""
This is probably a Dumb Git Question, but is there a tag in the repo for the new release? I go into my clone and type \"git tag\" and the latest one I see is 4.20130323.
"""]]

8
doc/design/assistant/blog/day_230__Mom/comment_2_2fa295ab6db0828cb725cfcfb6777822._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawln3ckqKx0x_xDZMYwa9Q1bn4I06oWjkog"
nickname="Michael"
subject="deletions by mistake?"
date="2013-04-06T04:58:09Z"
content="""
Let's say a family member deletes a file by mistake in a synced diretory? Looks like this kind of error is easy to go unnoticed. What would be a good way to handle this?
"""]]

10
doc/design/assistant/blog/day_230__Mom/comment_3_fafd7abec629290418334ddb015bf62c._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
nickname="joey"
subject="comment 3"
date="2013-04-06T16:26:57Z"
content="""
Weird, I don't know where the tag went. I've pushed a new one.
If a file is deleted, it's still there in git, and git-annex hangs onto its contents. You need a git history browser to get it back of course.
"""]]

8
doc/design/assistant/blog/day_230__Mom/comment_4_450cac0f2e82c94fd34b527ae05ef1b8._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawlUbH3eytydcwlWqv8oauE2Jg4NwcV9uA0"
nickname="Anna"
subject="me!"
date="2013-04-06T18:22:30Z"
content="""
I want in on the family repository! :-)
"""]]

15
doc/forum/__34__unable_to_resolve_reference_refs__47__heads__47__git-annex__34__/comment_2_d67793f7c969f64943d1fd54a1208c2b._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="spwhitton"
ip="163.1.166.255"
subject="comment 2"
date="2013-04-06T19:06:24Z"
content="""
Thanks for taking the time to reply.
1) The corruption spread between repositories so I resorted to restoring from a backup from some days ago, and then I restored newly added files by manually copying the symlinks from the old repo into the new one. Of course I can't update the git-annex branch by hand. I've run `git annex fsck`: does that re-create the location log information for the symlinks that I re-added, at least for the local repository even if it doesn't know about copies elsewhere?
2) I initially tried to git clone from my restored backup, rather than just moving the restore into place. But then while this clone showed no errors on a `git fsck --full`, any git-annex command, such as `init` (following [this](http://git-annex.branchable.com/tips/what_to_do_when_a_repository_is_corrupted/)), gives the following sort of error:
error: invalid object 100644 <long-SHA-string> for '<path to one of git annex's log files>'
(unfortunately I lost my xterm so don't have one of my actual errors in full). Can you think of any reason why doing a clone of the backup copy would cause this? Instead I have just mv'd the backup copy into place and it works fine.
"""]]