From a72d1d2c73f7d7cd77309c407757e5e0fd264489 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Tue, 11 Jun 2013 15:14:44 +0000 Subject: [PATCH 01/17] Added a comment --- .../comment_7_c713f6316d889c8fc52326f21375c1c4._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_7_c713f6316d889c8fc52326f21375c1c4._comment diff --git a/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_7_c713f6316d889c8fc52326f21375c1c4._comment b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_7_c713f6316d889c8fc52326f21375c1c4._comment new file mode 100644 index 0000000000..754ffe774e --- /dev/null +++ b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_7_c713f6316d889c8fc52326f21375c1c4._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 7" + date="2013-06-11T15:14:44Z" + content=""" +Re-reading, I see you're using Fedora and OSX. +"""]] From 6b969379e8002eeb7828094d91c5558952e9aaf9 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Tue, 11 Jun 2013 15:17:56 +0000 Subject: [PATCH 02/17] Added a comment --- .../comment_8_6dd23bab7983b8b1f938dd4f21a16f5a._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_8_6dd23bab7983b8b1f938dd4f21a16f5a._comment diff --git a/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_8_6dd23bab7983b8b1f938dd4f21a16f5a._comment b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_8_6dd23bab7983b8b1f938dd4f21a16f5a._comment new file mode 100644 index 0000000000..400f7597f3 --- /dev/null +++ b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_8_6dd23bab7983b8b1f938dd4f21a16f5a._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 8" + date="2013-06-11T15:17:56Z" + content=""" +I can reproduce the bug. Doesn't look likely to involve a race, since it happens every time. +"""]] From 0af040f4318e61989a78e833e824c0e9e4348e0e Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Tue, 11 Jun 2013 15:30:14 +0000 Subject: [PATCH 03/17] Added a comment --- ...t_9_961c8f968eff0b39a85b607ee3f7630d._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_9_961c8f968eff0b39a85b607ee3f7630d._comment diff --git a/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_9_961c8f968eff0b39a85b607ee3f7630d._comment b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_9_961c8f968eff0b39a85b607ee3f7630d._comment new file mode 100644 index 0000000000..419abf6989 --- /dev/null +++ b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_9_961c8f968eff0b39a85b607ee3f7630d._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 9" + date="2013-06-11T15:30:14Z" + content=""" +My guess about the write bit seems to be spot on. Which does mean it's a race, just one that happens to be easy to reproduce. It does not happen every time, but 1 time out of 10 or more often. + +You can try commenting out the `preventWrite` line in `Command/Add.hs` and rebuilding to see it fix it for you too. I will need to think long and hard about how to make files be ingested safely without turning off the write bit. But, I had been meaning to work on that at some point anyway, so good to have this bug to make it happen. + +I instrumented latexmk's call to `$out_handle->open` to see how it's failing: + +open failed: Permission denied 256 + +Which confirms the problem. It seems that it first creates the file, and then closes it, and then re-opens it to write to it some more. git-annex gets in between these two calls and messes up the permissions behind its back. +"""]] From 49ea56e81cd45a10c2c85a6dc376352199507bef Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawl9J51AO9t75xN5k0sJgg8taUo4y0a4hpQ" Date: Tue, 11 Jun 2013 19:04:17 +0000 Subject: [PATCH 04/17] --- doc/install/OSX.mdwn | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/doc/install/OSX.mdwn b/doc/install/OSX.mdwn index 97d956d893..b230f15657 100644 --- a/doc/install/OSX.mdwn +++ b/doc/install/OSX.mdwn @@ -41,8 +41,9 @@ brew link libxml2 cabal update PATH=$HOME/bin:$PATH PATH=$HOME/.cabal/bin:$PATH +cabal install c2hs --bindir=$HOME/bin cabal install gnuidn -cabal install c2hs git-annex --bindir=$HOME/bin +cabal install git-annex --bindir=$HOME/bin ## using MacPorts From f82b055abab3742c1d5ceb1b531db2cd5b963507 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU" Date: Tue, 11 Jun 2013 19:27:04 +0000 Subject: [PATCH 05/17] Added a comment --- ...ment_10_fadf06f5ab34e36ab130536ec55afc8e._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_10_fadf06f5ab34e36ab130536ec55afc8e._comment diff --git a/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_10_fadf06f5ab34e36ab130536ec55afc8e._comment b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_10_fadf06f5ab34e36ab130536ec55afc8e._comment new file mode 100644 index 0000000000..79cfafa17b --- /dev/null +++ b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_10_fadf06f5ab34e36ab130536ec55afc8e._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawnXybLxkPMYpP3yw4b_I6IdC3cKTD-xEdU" + nickname="Matt" + subject="comment 10" + date="2013-06-11T19:27:04Z" + content=""" +First off, I really like git-annex :-) + +Secondly, if I make the change as suggested, what are the consequences? When you add files to the annex back-end it may still be open and being written to? But then the next hash-function will reveal the differences of an incomplete upload and fix things.... But it may be too late as it's sent to other repositories...hmmmmm...I guess I want to know if I do this will my data be safe? I suspect not. + +Perhaps the race condition could be mitigated against (not solved) by simply introducing a slight delay? If only 5 secs it will catch many of these cases. And longer would prevent git committing files that I save, realize I've slightly got wrong, tweak and save again. +"""]] From 7353aa5e7aad3cea8bff556770ff6f301b1978df Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkxmke7K8gEXleVRuQvCK5LHPLIzQA6s0E" Date: Tue, 11 Jun 2013 20:34:13 +0000 Subject: [PATCH 06/17] --- doc/forum/Overwriting_data_without_getting_it.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/forum/Overwriting_data_without_getting_it.mdwn diff --git a/doc/forum/Overwriting_data_without_getting_it.mdwn b/doc/forum/Overwriting_data_without_getting_it.mdwn new file mode 100644 index 0000000000..65ade06b34 --- /dev/null +++ b/doc/forum/Overwriting_data_without_getting_it.mdwn @@ -0,0 +1,3 @@ +My collaborators and I use git annex to track various large data files (among some smaller metadata files managed by ordinary git). Some of these data files need to change completely -- the old ones were just wrong. So I do a git checkout, but don't `git annex get` because it would just be a waste of time and bandwidth. This means that my "data files" are just broken symlinks. Now, I find that by making the necessary directories under `.git/annex/objects/`, I can write to these files in the usual directory structure (not through `.git/annex/objects`). But now they are are longer symlinks, and git/git-annex doesn't seem to realize that anything has changed. Is this recoverable? + +Would it have been better to just `git rm` (or something) the original version of the file, commit that, and then add the new data? And if so, how should I go about this now that I've created these many very large files? If not, what would be the preferred way to do this? From 54cd08d7f0fe3bcaf33380cd3d53ba4f75f7c9a6 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawl9J51AO9t75xN5k0sJgg8taUo4y0a4hpQ" Date: Tue, 11 Jun 2013 22:28:52 +0000 Subject: [PATCH 07/17] Added a comment --- ..._e85c3fa1d17f1d6ec625b9c4f9b698c3._comment | 47 +++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment diff --git a/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment new file mode 100644 index 0000000000..6220a44166 --- /dev/null +++ b/doc/forum/help_running_git-annex_on_top_of_existing_repo/comment_6_e85c3fa1d17f1d6ec625b9c4f9b698c3._comment @@ -0,0 +1,47 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawl9J51AO9t75xN5k0sJgg8taUo4y0a4hpQ" + nickname="Daniel" + subject="comment 6" + date="2013-06-11T22:28:52Z" + content=""" +This is what I ended up doing. +[https://gist.github.com/ifnull/5761255](https://gist.github.com/ifnull/5761255) + +Basically you just add the extensions of the files you want to exclude to .gitignore_large_binaries and run \"git a .\" instead of \"git add .\" + + ####################### + # Setup + ####################### + mkdir annex-test + cd annex-test + git init + git annex init master + + ####################### + # Fab setup task + ####################### + git config --local core.excludesfile ./.gitignore_large_binaries + git config --local alias.a '! sh ./git-add.sh' + + ####################### + # git a (git-add.sh) + ####################### + + # Generate annex include arg from .gitignore_large_binaries + include_str=\"--include='.lazy'\"; + + while read line + do + if [[ \"$line\" != *\"#\"* ]] && [[ \"$line\" != \"\" ]]; then + include_str=\"$include_str --or --include=${line}\"; + fi + done < \"./.gitignore_large_binaries\" + + # git annex add + git config --local core.excludesfile ./.gitignore; + git annex add $1 $include_str; + + # git add + git config --local core.excludesfile ./.gitignore_large_binaries; + git add $1 +"""]] From 55f133670d507ccc26971eb8e8e31327c3c7d427 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7" Date: Wed, 12 Jun 2013 00:47:22 +0000 Subject: [PATCH 08/17] Added a comment --- .../comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment diff --git a/doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment b/doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment new file mode 100644 index 0000000000..3ce2447bc7 --- /dev/null +++ b/doc/forum/performance_and_multiple_replication_problems/comment_2_e65b360706c66ede6e0e841b2ebbbfbc._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://me.yahoo.com/a/bBy7WkgQicYHIiiyj.Vm0TcMbxi2quzbPFef#6f9f7" + nickname="Frederik Vanrenterghem" + subject="comment 2" + date="2013-06-12T00:47:21Z" + content=""" +I have witnessed that second problem as well, to the point where I've stopped autostarting (and hence using) git annex for the moment. I'll try to get some debugging data. +"""]] From c506f3cc2f38130bf66c1134eb1cdcd95993c6bf Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawk3Wgg0XiqYFwM_Pw1RxZwlpNFi65g17sM" Date: Wed, 12 Jun 2013 01:12:24 +0000 Subject: [PATCH 09/17] Added a comment --- .../comment_3_b00dce2374aac6968317d05d23bcfaf7._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment diff --git a/doc/bugs/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment b/doc/bugs/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment new file mode 100644 index 0000000000..3442fb2b2b --- /dev/null +++ b/doc/bugs/Move_ssh_config_to___126____47__ssh__47__git-annex__47__config/comment_3_b00dce2374aac6968317d05d23bcfaf7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawk3Wgg0XiqYFwM_Pw1RxZwlpNFi65g17sM" + nickname="James" + subject="comment 3" + date="2013-06-12T01:12:24Z" + content=""" +Ah, ok, I presumed there was an option in git to set a per-repository ssh command. I've looked at vcsh, but I'm not that confident with git remotes, so I don't use it (I use hg). If a per-repository ssh command added to git, would you consider adding this? +"""]] From 87683fd95002c0b4dc6ab94c0ae7945483b326a5 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkxmke7K8gEXleVRuQvCK5LHPLIzQA6s0E" Date: Wed, 12 Jun 2013 02:36:39 +0000 Subject: [PATCH 10/17] --- doc/forum/Overwriting_data_without_getting_it.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Overwriting_data_without_getting_it.mdwn b/doc/forum/Overwriting_data_without_getting_it.mdwn index 65ade06b34..433651ee96 100644 --- a/doc/forum/Overwriting_data_without_getting_it.mdwn +++ b/doc/forum/Overwriting_data_without_getting_it.mdwn @@ -1,3 +1,3 @@ -My collaborators and I use git annex to track various large data files (among some smaller metadata files managed by ordinary git). Some of these data files need to change completely -- the old ones were just wrong. So I do a git checkout, but don't `git annex get` because it would just be a waste of time and bandwidth. This means that my "data files" are just broken symlinks. Now, I find that by making the necessary directories under `.git/annex/objects/`, I can write to these files in the usual directory structure (not through `.git/annex/objects`). But now they are are longer symlinks, and git/git-annex doesn't seem to realize that anything has changed. Is this recoverable? +My collaborators and I use git annex to track various large data files (among some smaller metadata files managed by ordinary git). Some of these data files need to change completely -- the old ones were just wrong. So I do a git checkout, but don't `git annex get` because it would just be a waste of time and bandwidth. This means that my "data files" are just broken symlinks. Now, I find that by making the necessary directories under `.git/annex/objects/`, I can write to these files in the usual way. The symlinks are preserved, and the files they link to now exist and are full of my corrected data. But now git/git-annex doesn't seem to realize that anything has changed. Is this recoverable? Would it have been better to just `git rm` (or something) the original version of the file, commit that, and then add the new data? And if so, how should I go about this now that I've created these many very large files? If not, what would be the preferred way to do this? From c079d621171ff42084fb8b3e951a7207a97ab3ef Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkxmke7K8gEXleVRuQvCK5LHPLIzQA6s0E" Date: Wed, 12 Jun 2013 02:43:59 +0000 Subject: [PATCH 11/17] Corrected statement about status of symlinks --- doc/forum/Overwriting_data_without_getting_it.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Overwriting_data_without_getting_it.mdwn b/doc/forum/Overwriting_data_without_getting_it.mdwn index 433651ee96..ccd23b74e7 100644 --- a/doc/forum/Overwriting_data_without_getting_it.mdwn +++ b/doc/forum/Overwriting_data_without_getting_it.mdwn @@ -1,3 +1,3 @@ -My collaborators and I use git annex to track various large data files (among some smaller metadata files managed by ordinary git). Some of these data files need to change completely -- the old ones were just wrong. So I do a git checkout, but don't `git annex get` because it would just be a waste of time and bandwidth. This means that my "data files" are just broken symlinks. Now, I find that by making the necessary directories under `.git/annex/objects/`, I can write to these files in the usual way. The symlinks are preserved, and the files they link to now exist and are full of my corrected data. But now git/git-annex doesn't seem to realize that anything has changed. Is this recoverable? +My collaborators and I use git annex to track various large data files (among some smaller metadata files managed by ordinary git). Some of these data files need to change completely -- the old ones were just wrong. So I do a git checkout, but don't `git annex get` because it would just be a waste of time and bandwidth. This means that my "data files" are just broken symlinks. Now, I find that by making the necessary directories under `.git/annex/objects/`, I can write to these files in the usual way. The symlinks are preserved, and the files they link to now exist and are full of my corrected data. This seems like it's a problem because the hash has presumably changed. (I'm still a little fuzzy on how exactly git-annex works.) Also, git/git-annex doesn't seem to realize that anything has changed. Is this recoverable? Would it have been better to just `git rm` (or something) the original version of the file, commit that, and then add the new data? And if so, how should I go about this now that I've created these many very large files? If not, what would be the preferred way to do this? From 715077747d69f45e65f152ef8e6ce293f8d49ee6 Mon Sep 17 00:00:00 2001 From: "http://yarikoptic.myopenid.com/" Date: Wed, 12 Jun 2013 02:56:27 +0000 Subject: [PATCH 12/17] --- ...t_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn new file mode 100644 index 0000000000..6dd5c16df3 --- /dev/null +++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__.mdwn @@ -0,0 +1 @@ +Since all the annexed (in indirect mode) files are symlinks to topdir/.git/annex/... moving files among directories at different levels is not that straightforward since symlinks would get broken. And since there is not 'annex mv' command -- what is the best way? (unlock is not the resolution since it copies the file, which might be prohibitively large and inefficient) From f1e82d76506ec145a8c1195e7b8dbd0ba996c4f2 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Wed, 12 Jun 2013 16:42:54 +0000 Subject: [PATCH 13/17] Added a comment --- ...comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment diff --git a/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment new file mode 100644 index 0000000000..9eae8ef7ab --- /dev/null +++ b/doc/forum/What_is_the_best_way_to___34__git_annex_mv__34___file__63__/comment_1_02d305f307b4d2ff7acd98cb36508a2f._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-06-12T16:42:54Z" + content=""" +You can move the symlinks however you like (git mv, or regular mv and git add). + +To fix up broken symlinks, you can either run `git annex fix`, or just commit the move. The pre-commit hook fixes up links automatically. +"""]] From 561aeed47c4d682d7060126c6d81c053c381d15b Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Wed, 12 Jun 2013 16:57:52 +0000 Subject: [PATCH 14/17] Added a comment --- ..._f1c0199ee9bffcc84287370b89361294._comment | 26 +++++++++++++++++++ 1 file changed, 26 insertions(+) create mode 100644 doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment diff --git a/doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment b/doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment new file mode 100644 index 0000000000..a6092b1f21 --- /dev/null +++ b/doc/forum/Overwriting_data_without_getting_it/comment_1_f1c0199ee9bffcc84287370b89361294._comment @@ -0,0 +1,26 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 1" + date="2013-06-12T16:57:52Z" + content=""" +I think you're making this more complicated than it needs to be. You don't need to mess around with .git/annex/objects at all. You can replace git-annex symlinks with new files and git annex add the new content. + +For example: + +[[!format sh \"\"\" +joey@gnu:~/tmp/repo>git annex drop --force foo +drop foo ok +(Recording state in git...) +joey@gnu:~/tmp/repo>ls +foo@ +joey@gnu:~/tmp/repo>rm foo +joey@gnu:~/tmp/repo>echo \"new good contents\" > foo +joey@gnu:~/tmp/repo>git annex add foo +add foo (checksum...) ok +(Recording state in git...) +joey@gnu:~/tmp/repo>git commit -m add +[master ec3ed14] add + 1 file changed, 1 insertion(+), 1 deletion(-) +\"\"\"]] +"""]] From 122c599b82edff9bb488c072ea1a7f4452b0274f Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Wed, 12 Jun 2013 17:03:07 +0000 Subject: [PATCH 15/17] Added a comment --- ...omment_11_4a337f7b1140c45e5dd660b40202f696._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_11_4a337f7b1140c45e5dd660b40202f696._comment diff --git a/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_11_4a337f7b1140c45e5dd660b40202f696._comment b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_11_4a337f7b1140c45e5dd660b40202f696._comment new file mode 100644 index 0000000000..99787d4c69 --- /dev/null +++ b/doc/bugs/file_access__47__locking_issues_with_the_assitant/comment_11_4a337f7b1140c45e5dd660b40202f696._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 11" + date="2013-06-12T17:03:07Z" + content=""" +There's an annex.delayadd git config setting you can use that makes it wait a specified number of seconds before committing. So it would indeed be a workaround to set: `git config annex.delayadd 2` + +However, I'm pretty confident I can entirely avoid this problem, safely. +"""]] From 9af796772864b7de04b08a5f96fc6805783e4c39 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawkxmke7K8gEXleVRuQvCK5LHPLIzQA6s0E" Date: Wed, 12 Jun 2013 17:14:11 +0000 Subject: [PATCH 16/17] Added a comment --- .../comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment diff --git a/doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment b/doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment new file mode 100644 index 0000000000..698d00c35b --- /dev/null +++ b/doc/forum/Overwriting_data_without_getting_it/comment_2_6a1d08dbca206129ef6cf8aa97daeee1._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://www.google.com/accounts/o8/id?id=AItOawkxmke7K8gEXleVRuQvCK5LHPLIzQA6s0E" + nickname="Michael" + subject="comment 2" + date="2013-06-12T17:14:11Z" + content=""" +Yes, it seems I was making this more complicated than it needed to be. Just a plain rm seems to work. But just to be clear, I never had the data so I don't need to drop it, right? (By which I mean, is there some other function of drop that I don't understand?) +"""]] From d9a85abfd030cd141c196149d881ddb5867c42b2 Mon Sep 17 00:00:00 2001 From: "http://joeyh.name/" Date: Wed, 12 Jun 2013 17:15:26 +0000 Subject: [PATCH 17/17] Added a comment --- .../comment_3_52958e76e506fdbb6b533681ab619b3b._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment diff --git a/doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment b/doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment new file mode 100644 index 0000000000..19292b8707 --- /dev/null +++ b/doc/forum/Overwriting_data_without_getting_it/comment_3_52958e76e506fdbb6b533681ab619b3b._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://joeyh.name/" + nickname="joey" + subject="comment 3" + date="2013-06-12T17:15:26Z" + content=""" +Right. I just put the drop in there to get my repository to the state you described. +"""]]