From 3ded849532216d97ac6004146445fbcc85769054 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" Date: Sun, 27 Mar 2011 17:37:07 +0000 Subject: [PATCH 1/5] --- ...ex_has_issues_with_git_when_staging__47__commiting_logs.mdwn | 2 ++ 1 file changed, 2 insertions(+) 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 f1290a8186..b7944b418c 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 From 1fccea5154ac5b8e10fa387e2230e3a4103cef3b Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkSq2FDpK2n66QRUxtqqdbyDuwgbQmUWus" Date: Sun, 27 Mar 2011 17:48:51 +0000 Subject: [PATCH 2/5] --- ...nex_directory_hashing_problems_on_osx.mdwn | 44 +++++++++++++++++++ 1 file changed, 44 insertions(+) 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 2e6b138c16..e5937fe83f 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 + +
+## with ignorecase=false
+commit bb024c6fd7482b2d10f60ae899cb7a949aca1ad8
+Author: Jimmy Tang 
+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
+
+ +>>>>> and without changing ignorecase + +
+commit 909a089158ffb98f8e91f98905e2bfdc7234666f
+Author: Jimmy Tang 
+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
+
+ 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 From cd451760c33b702616727f91b0364601609491c5 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" Date: Sun, 27 Mar 2011 20:11:20 +0000 Subject: [PATCH 3/5] --- doc/forum/batch_check_on_remote_when_using_copy.mdwn | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 doc/forum/batch_check_on_remote_when_using_copy.mdwn 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 0000000000..355d98f04b --- /dev/null +++ b/doc/forum/batch_check_on_remote_when_using_copy.mdwn @@ -0,0 +1,5 @@ +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. + +-- RichiH From bec63186ea0b9b25e2387685c209578bc316397d Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" Date: Sun, 27 Mar 2011 20:14:47 +0000 Subject: [PATCH 4/5] --- doc/forum/batch_check_on_remote_when_using_copy.mdwn | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/forum/batch_check_on_remote_when_using_copy.mdwn b/doc/forum/batch_check_on_remote_when_using_copy.mdwn index 355d98f04b..0f20ab6454 100644 --- a/doc/forum/batch_check_on_remote_when_using_copy.mdwn +++ b/doc/forum/batch_check_on_remote_when_using_copy.mdwn @@ -2,4 +2,7 @@ When I copy my local repository with SHA* to a remote repo with SHA*, every sing 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 From 834309d1d0c96f5f1ca9530c9622a24234242e28 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawl9sYlePmv1xK-VvjBdN-5doOa_Xw-jH4U" Date: Sun, 27 Mar 2011 20:39:14 +0000 Subject: [PATCH 5/5] --- ..._version_upgrade_leaves_repo_unusable.mdwn | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 doc/bugs/backend_version_upgrade_leaves_repo_unusable.mdwn 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 0000000000..16a0ca3744 --- /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