From aa5d3edd97a89c022566d076a5ecbc6374dedaf9 Mon Sep 17 00:00:00 2001 From: edward Date: Thu, 13 Oct 2016 21:16:59 +0000 Subject: [PATCH 1/8] fix typo --- doc/devblog/day_420__delayed_debugging.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/devblog/day_420__delayed_debugging.mdwn b/doc/devblog/day_420__delayed_debugging.mdwn index 50c42965e0..8ab3ecd972 100644 --- a/doc/devblog/day_420__delayed_debugging.mdwn +++ b/doc/devblog/day_420__delayed_debugging.mdwn @@ -7,7 +7,7 @@ Finally got back to that today. Luckily, I *was* able to reproduce the bug using felix's repo. The bug only occurs when there's a change deep in a tree of an adjusted branch, and not always then. After staring at it for a couple of hours, I finally found the problem; a modification flag was not -getting propigated in this case, and some changes made deep in the tree +getting propagated in this case, and some changes made deep in the tree were not getting included into parent trees. So, I think I've fixed it, but need to look at it some more to be sure, and From f622e866e15da4bd15978ab4d80fcb255830e0da Mon Sep 17 00:00:00 2001 From: "https://launchpad.net/~stephane-gourichon-lpad" Date: Fri, 14 Oct 2016 07:02:42 +0000 Subject: [PATCH 2/8] Added a comment: git-annex-undo removes files, possibly destroying information? Please explain. --- ..._3466520304aa164ec44ed4e9d67590e7._comment | 55 +++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment diff --git a/doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment b/doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment new file mode 100644 index 0000000000..8155ec0e7b --- /dev/null +++ b/doc/git-annex-undo/comment_1_3466520304aa164ec44ed4e9d67590e7._comment @@ -0,0 +1,55 @@ +[[!comment format=mdwn + username="https://launchpad.net/~stephane-gourichon-lpad" + nickname="stephane-gourichon-lpad" + avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089" + subject="git-annex-undo removes files, possibly destroying information? Please explain." + date="2016-10-14T07:02:42Z" + content=""" +Hello, + +## Context + +Thank you for git-annex. I'm progressing in learning how to use it. Seems to work as intended with only annexed files. + +I actually need mixed content repository and like the idea of `annex.largefiles` deciding which files go into the annex. + +While experimenting with mixed content repository, I had `git-annex-undo` destroy information twice. Or perhaps I did something wrong? + +## What happened + +Here's my .gitattributes + +``` +*.NEF annex.largefiles=anything +*.JPG annex.largefiles=anything +*.jpg annex.largefiles=anything + +``` + +I had a directory (say, `newdir`) with some jpg and some other files, not known by git or git-annex so far. + +Based on [https://git-annex.branchable.com/tips/largefiles/](https://git-annex.branchable.com/tips/largefiles/) I expected both `git add` and `git annex add` to add NEF JPG jpg to the annex, and other files as regular git files. + +In case of problem, I expected `git annex undo` to revert state to the one just before the last command (which is: full of my regular files, not symlinks or empty). + +* `git add newdir` added them *all* as *regular* files, not partly in the annex as expected. Surprised, I wanted to undo and try another command. +* `git annex undo` emptied `newdir` completely. Wow! Fortunately these were copies, else they would have been gone forever! To be fair I have not checked at that point if files had been copied in annex, which as only copy would still be a mess because file names would have been lost anyway. + +I used `git reset ` to revert state git-style, checked with `git status` that state was indeed back to pre-add (newdir empty, not known to git), then copied the files again from their source. + +* `git annex add newdir` added them all as *annexed* files, replacing with links, not partly as regular files as expected. +* `git annex undo` emptied `newdir` completely. I expected my regular files back in place. + +I had the intended result by using `git add` on regular files and `git annex add` to add files to be annexed. As if `.gitattributes` were absent. + +git-annex compiled on Debian unstable as of 2016-10-13 from git source, commit 3135d35094aa5453ef7a5f12762e00e0139a6dbb. + +## Questions + +* Have I explained situation clearly? +* Did `git annex add` behave as intended by you? Wasn't it supposed to automatically decide which files go to the annex? +* Did `git annex undo` behave as intended by you? Wasn't it supposed to revert working directory to the state just before the wrong \"add\"? +* Have I used `.gitattributes`, `add` commands correctly? + +Thank you. +"""]] From 63d02ae1d904d5a018816454a7193027a14c560b Mon Sep 17 00:00:00 2001 From: "https://launchpad.net/~stephane-gourichon-lpad" Date: Fri, 14 Oct 2016 07:23:51 +0000 Subject: [PATCH 3/8] Added a comment --- ...t_2_3dba1a993cbd357bdaa453366c0185cd._comment | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment diff --git a/doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment b/doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment new file mode 100644 index 0000000000..8d36310537 --- /dev/null +++ b/doc/git-annex-undo/comment_2_3dba1a993cbd357bdaa453366c0185cd._comment @@ -0,0 +1,16 @@ +[[!comment format=mdwn + username="https://launchpad.net/~stephane-gourichon-lpad" + nickname="stephane-gourichon-lpad" + avatar="http://cdn.libravatar.org/avatar/02d4a0af59175f9123720b4481d55a769ba954e20f6dd9b2792217d9fa0c6089" + subject="comment 2" + date="2016-10-14T07:23:51Z" + content=""" +Adding this to `.gitattributes`: + +``` +*.xmp annex.largefiles=nothing +``` + +Causes `git-annex add` to behave as expected. Questions about `git annex undo` behavior remain. + +"""]] From 867a4ac4e857dd3c7b68b704e3df49b005819bc2 Mon Sep 17 00:00:00 2001 From: "https://launchpad.net/~helpunclejackoff" Date: Sat, 15 Oct 2016 10:12:17 +0000 Subject: [PATCH 4/8] Added a comment: Dumb old me.... --- ...ment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment diff --git a/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment b/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment new file mode 100644 index 0000000000..6b10f34f52 --- /dev/null +++ b/doc/bugs/Walkthrough_incomplete_for_special_remotes_in_commandline/comment_1_f4d4ddf73895fdcbf40d64992e88b7a8._comment @@ -0,0 +1,13 @@ +[[!comment format=mdwn + username="https://launchpad.net/~helpunclejackoff" + nickname="helpunclejackoff" + avatar="http://cdn.libravatar.org/avatar/5a03d3e717ff477309d5b5f5726fcd3b51bb5c6b2241e796f93bd4f340426d04" + subject="Dumb old me...." + date="2016-10-15T10:12:17Z" + content=""" +In my script I was using `git add` instead of `git annex add`... + +All is good now. + +Cheers! +"""]] From 7adc7d5068cdedd67c92505370bbd4101c5cf62f Mon Sep 17 00:00:00 2001 From: "ryan@d4f0c2d3daacb5ec3a2945bca06f66decad4bfb5" Date: Sat, 15 Oct 2016 18:42:07 +0000 Subject: [PATCH 5/8] Git Annex Assistant occasionally replaces files with dangling symlinks. --- ...ssionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn diff --git a/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn new file mode 100644 index 0000000000..18f2e88b8d --- /dev/null +++ b/doc/forum/Git_Annex_Assistant_Occassionally_Loses_Files_and_Gives_Dangling_Symlink.mdwn @@ -0,0 +1,9 @@ +I am using the git annex assistant between two linux machines. Sometimes, it seems to "lose" a file, having a dangling symlink of it. Fsck shows that there are no known copies of the file in the repositories, but if I do a search in .git/annex/objects, I'm able to find the file. + + +I'm using git annex 6.20160923+gitgd1dabb3-1~ndall+1 and direct mode repositories thanks to the assistant. + +Any advice would be highly appreciated. Right now, I can't get it to consistently do this behavior, but any help would be appreciated, including what I should post, look for, etc. for more troubleshooting. + +Thanks again, +Ryan From 7877c8d58f45fac87c5c0fe3437f8d9bb0a892fa Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" Date: Mon, 17 Oct 2016 15:58:54 +0000 Subject: [PATCH 6/8] initial suggestion --- doc/todo/unlock_--read-only.mdwn | 1 + 1 file changed, 1 insertion(+) create mode 100644 doc/todo/unlock_--read-only.mdwn diff --git a/doc/todo/unlock_--read-only.mdwn b/doc/todo/unlock_--read-only.mdwn new file mode 100644 index 0000000000..d23b9425d4 --- /dev/null +++ b/doc/todo/unlock_--read-only.mdwn @@ -0,0 +1 @@ +"annex unlock" in thin mode of v6 hard-links key into the file location and makes it RW. This is obviously for the case where modifications to the file need to be done and danger is understood. In my case, I need unlock to avoid having symlinks in the files since some software doesn't digest them well (might copy without dereferencing or dereference and look for neighboring files in the directory), and I want to use unlock to pretty much provide "symlink-free" view of the tree BUT at least with some protection, which could be given if files are unlocked read-only, so no inplace modifications could happen without explicit change of the permissions. From 82fac4f0b70c313a23207673a53cdf24072c4346 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" Date: Mon, 17 Oct 2016 15:59:32 +0000 Subject: [PATCH 7/8] added meta for myself --- doc/todo/unlock_--read-only.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/todo/unlock_--read-only.mdwn b/doc/todo/unlock_--read-only.mdwn index d23b9425d4..0c33cb173a 100644 --- a/doc/todo/unlock_--read-only.mdwn +++ b/doc/todo/unlock_--read-only.mdwn @@ -1 +1,3 @@ "annex unlock" in thin mode of v6 hard-links key into the file location and makes it RW. This is obviously for the case where modifications to the file need to be done and danger is understood. In my case, I need unlock to avoid having symlinks in the files since some software doesn't digest them well (might copy without dereferencing or dereference and look for neighboring files in the directory), and I want to use unlock to pretty much provide "symlink-free" view of the tree BUT at least with some protection, which could be given if files are unlocked read-only, so no inplace modifications could happen without explicit change of the permissions. + +[[!meta author=yoh]] From 17cce14d19a6a54f65ae4305be0c45816c9c5a23 Mon Sep 17 00:00:00 2001 From: "https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4" Date: Mon, 17 Oct 2016 16:17:59 +0000 Subject: [PATCH 8/8] original whining --- ...to_have_copied_files_appear_correctly.mdwn | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn diff --git a/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn b/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn new file mode 100644 index 0000000000..11cece2b6c --- /dev/null +++ b/doc/bugs/remote_repository_must_be_version_6_as_well_to_have_copied_files_appear_correctly.mdwn @@ -0,0 +1,32 @@ +### Please describe the problem. + +Originally spotted/reported: https://github.com/datalad/datalad/issues/1020 + +If that is mandatory, then I guess there should be some error message. + +### What steps will reproduce the problem? + +create a remote repo without specifying version, i.e. of version 5 and copy data into it + +### What version of git-annex are you using? On what operating system? + +6.20160923+gitgd1dabb3-1~ndall+1 + +### Please provide any additional information below. + +Output from running http://www.onerussian.com/tmp/v6-push.sh with argument which specifies annex version within remote + +[[!format sh """ + +$> ./v6-push.sh 5 2>&1 | grep '>>>' +>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat +>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat + +$> ./v6-push.sh 6 2>&1 | grep '>>>' +>>> /annex/objects/SHA256E-s4--181210f8f9c779c26da1d9b2075bde0127302ee0e3fca38c9a83f5b1dd8e5d3b.dat +>>> 123 + +"""]] + + +[[!meta author=yoh]]