diff options
author | 2011-03-27 17:47:06 -0400 | |
---|---|---|
committer | 2011-03-27 17:47:06 -0400 | |
commit | 305b11d7c29b61e4fe328460fd50af590b4df6f6 (patch) | |
tree | ee44c1e1e78ae0f058ae19de9dc9576921228a1f | |
parent | fb47e884040c3d95ceaa9e9bbc442fdf14abdd3a (diff) | |
parent | 834309d1d0c96f5f1ca9530c9622a24234242e28 (diff) |
Merge remote-tracking branch 'branchable/master'
4 files changed, 82 insertions, 0 deletions
diff --git a/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn b/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn new file mode 100644 index 000000000..16a0ca374 --- /dev/null +++ b/doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn @@ -0,0 +1,28 @@ +foo is a local repo, bar is a bare remote. + +I upgraded foo's git-annex to 0.20110325 and upgraded a local repo backend to version 2. I then ran `git annex copy . --to bar` and checked the remote. This created WORM:SHA512--123123 files in annex/objects. Understandable but unwanted. So I upgraded git-annex on bar's machine, as well. + + % git annex copy . --to bar + copy quux (checking bar) git-annex-shell: Repository version 1 is not supported. Upgrade this repository: git-annex upgrade (to bar) + git-annex-shell: Repository version 1 is not supported. Upgrade this repository: git-annex upgrade + rsync: connection unexpectedly closed (0 bytes received so far) [sender] + rsync error: error in rsync protocol data stream (code 12) at io.c(601) [sender=3.0.7] + + rsync failed -- run git annex again to resume file transfer + failed + +Running `git annex upgrade` on bar's machine I get: + + % git annex upgrade + upgrade (v1 to v2) (moving content...) git-annex: Prelude.read: no parse + +Again, bar is a bare repo. +Running the copy job again, I am still getting the same error as above (as expected). Partial contents of annex/objects on bar: + + [...] + SHA512:123 + WORM:SHA512--234 + [...] + + +-- RichiH diff --git a/doc/bugs/git-annex_directory_hashing_problems_on_osx.mdwn b/doc/bugs/git-annex_directory_hashing_problems_on_osx.mdwn index 2e6b138c1..e5937fe83 100644 --- a/doc/bugs/git-annex_directory_hashing_problems_on_osx.mdwn +++ b/doc/bugs/git-annex_directory_hashing_problems_on_osx.mdwn @@ -30,6 +30,9 @@ this has somewhat confused git when it tries to stage/merge files, I didn't noti >>> If you copied `.git/` over, perhaps you got a git repo without >>> core.ignorecase set right for the filesystem it landed on? + +>>>> I usually git clone or do a fresh repository and pull things in, I was also unaware of this ignorecase setting as well. + >>> >>> Something like this might reproduce it: @@ -51,6 +54,47 @@ this has somewhat confused git when it tries to stage/merge files, I didn't noti >>>> if it thought 3 distinct files had been committed. >>>> --[[Joey]] +>>>>> Doing the above test on a HFS+ partition yields this + +<pre> +## with ignorecase=false +commit bb024c6fd7482b2d10f60ae899cb7a949aca1ad8 +Author: Jimmy Tang <jtang@exia> +Date: Sun Mar 27 18:40:24 2011 +0100 + + commit + +diff --git a/Foo/bar b/Foo/bar +new file mode 100644 +index 0000000..e69de29 +diff --git a/fOo/bar b/fOo/bar +new file mode 100644 +index 0000000..e69de29 +diff --git a/fOo/other b/fOo/other +new file mode 100644 +index 0000000..e69de29 +diff --git a/foo/bar b/foo/bar +new file mode 100644 +index 0000000..e69de29 +</pre> + +>>>>> and without changing ignorecase + +<pre> +commit 909a089158ffb98f8e91f98905e2bfdc7234666f +Author: Jimmy Tang <jtang@exia> +Date: Sun Mar 27 18:46:57 2011 +0100 + + commit + +diff --git a/Foo/bar b/Foo/bar +new file mode 100644 +index 0000000..e69de29 +diff --git a/Foo/other b/Foo/other +new file mode 100644 +index 0000000..e69de29 +</pre> + Also I came across this when I accidentally annexed some files in the .git-annex directory and it cause git-annex/git to be very unhappy when i pulled the repo to somewhere else. It might be worth teaching git-annex to disallow annex'ing of files inside the .git-annex/.git directories. > There is a guard against `git annex add .git-annex/foo`, but it doesn't diff --git a/doc/bugs/git-annex_has_issues_with_git_when_staging__47__commiting_logs.mdwn b/doc/bugs/git-annex_has_issues_with_git_when_staging__47__commiting_logs.mdwn index f1290a818..b7944b418 100644 --- a/doc/bugs/git-annex_has_issues_with_git_when_staging__47__commiting_logs.mdwn +++ b/doc/bugs/git-annex_has_issues_with_git_when_staging__47__commiting_logs.mdwn @@ -14,3 +14,5 @@ For now it's just a bit of extra work for me when it does occur but it does not >>> I've never seen git refuse to commit staged files. There would have to >>> be some error message? --[[Joey]] + +>>>> there were no error messages at all diff --git a/doc/forum/batch_check_on_remote_when_using_copy.mdwn b/doc/forum/batch_check_on_remote_when_using_copy.mdwn new file mode 100644 index 000000000..0f20ab645 --- /dev/null +++ b/doc/forum/batch_check_on_remote_when_using_copy.mdwn @@ -0,0 +1,8 @@ +When I copy my local repository with SHA* to a remote repo with SHA*, every single file is checked by itself which seems rather inefficient. When my remote is accessed via ssh, git-annex opens a new connections for every check. If you are not using a ssh key or key agent, this gets tedious... + +For all locked files, either git's built-in mechanisms should be used or, if that's not possible, a few hundred checksums (assuming SHA* backend) should be transfered at once and then checked locally before deciding that to transfer. + +Once all checks are done, one single transfer session should be started. Creating new sessions and waiting for TCP's slowstart to get going is a lot less than efficient. + + +-- RichiH |