From 0e5d23fee1a2d54408e206a57d4cf73a3018cb38 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawk0Sr9y7EcI5OhPk4GteZiHVxaoC0DmJ-E" Date: Tue, 3 Jun 2014 13:27:43 +0000 Subject: [PATCH 01/18] --- ..._or_Dropbox...__41___substitute__63__.mdwn | 76 +++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn diff --git a/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn new file mode 100644 index 0000000000..0b49f422fa --- /dev/null +++ b/doc/forum/Can_git_annex___40__mostly__41___be_an_Ubuntu_One___40__or_Dropbox...__41___substitute__63__.mdwn @@ -0,0 +1,76 @@ +Hi, I tried with several git annex versions, on 3 different clients, and using 2 different remotes (an home server and box.com) and trying out different remotes setups but I've been unable to get git annex working as I expected. + + +I used the assistant for setup, I can sync files between clients just fine if they're connected at the same time, but if I sync a file from client A to the remotes when client B is off, and then later I turn off client A and power on client B, I've never been able to successfully sync files. + +on client B, inside .git/annex/daemon.log there's nothing interesting: just messages like: + +```(scanning...) [2014-06-03 14:53:26 CEST] Watcher: Performing startup scan + +Already up-to-date.``` + +`git annex sync` just outputs + +`"commit ok"` + +and `git annex list`: + +``` +here + +|berdario + +||soloud + +|||web + +||||box.com + +||||| + +XX__X IMG_20130202_100444.jpg + +XXX_X cookies.png + +XXX_X dancingllama.png + +XXX_X dario_bertini_cv.pdf + +XX__X steam_latest.deb +``` + +while this is what I get on client A: + +``` +here + +|berdario + +||web + +|||box.com + +|||| + +XX_X IMG_20130202_100444.jpg + +X__X Russian Lesson 5 - Wikibooks, open books for an open world.html + +XX_X cookies.png + +XX_X dancingllama.png + +XX_X dario_bertini_cv.pdf + +XX_X steam_latest.deb +``` + +(they're just a bunch of random files I'm using to test it, both clients are called berdario, soloud is the home server (currently down) and the other working remote is box.com) + +As you can see the russian wikibooks html file is successfully synced with the remotes, but client B is unable to see it... + +I tried to set the remotes as incremental backup, full backup, transfer, client (!?) but none of these settings work. + +Is git annex not what I'm looking for? Is it supposed to work only on contemporarily connected clients? + +Thanks From 7ff0905a2a41986872c18cf89ebac2d37ebd2112 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q" Date: Tue, 3 Jun 2014 14:44:34 +0000 Subject: [PATCH 02/18] question on view branches behaviour: they never get deleted, why? --- ...views___40__branches__41___never_get_deleted.mdwn | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/forum/views___40__branches__41___never_get_deleted.mdwn diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn new file mode 100644 index 0000000000..d8b071014b --- /dev/null +++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn @@ -0,0 +1,12 @@ +Hello everyone, +I would like to know if this is normal behavior or if it's a problem with my repository: + +Whenever I set a view with + +git annex view attr="\*"' + +a new branch representing the selected view gets created, as expected. The problem is that when I switch back to master ('git checkout master' or even 'git annex vpop') the view branch stays there, and all subsequent operations on the annex also consider the view branch, resulting a great slowdown if one has done many views (attr="this", attr="that", etc.). Is this normal? If so, why is it necessary for the branch to stay on? Does it speed up going back to the branch? Redoing git annex view attr="*" does not seem to take less time. + +Am I doing it wrong? Should I be deleting used view branches on my own? How? + +thanks for your replies. From 241620ba7a1c0c49aca5d385595617a9a3081408 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q" Date: Tue, 3 Jun 2014 15:44:11 +0000 Subject: [PATCH 03/18] --- doc/forum/views___40__branches__41___never_get_deleted.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn index d8b071014b..93f2f99065 100644 --- a/doc/forum/views___40__branches__41___never_get_deleted.mdwn +++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn @@ -10,3 +10,5 @@ a new branch representing the selected view gets created, as expected. The probl Am I doing it wrong? Should I be deleting used view branches on my own? How? thanks for your replies. + +EDIT: I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". From fc1c817341a49973996c74125e15bf422d627247 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q" Date: Tue, 3 Jun 2014 15:45:05 +0000 Subject: [PATCH 04/18] --- doc/forum/views___40__branches__41___never_get_deleted.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn index 93f2f99065..618a8cc14a 100644 --- a/doc/forum/views___40__branches__41___never_get_deleted.mdwn +++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn @@ -11,4 +11,4 @@ Am I doing it wrong? Should I be deleting used view branches on my own? How? thanks for your replies. -EDIT: I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". +EDIT: I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this? From a465bf636f5645b3bd710d8b207759c84764d8f7 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q" Date: Tue, 3 Jun 2014 15:45:55 +0000 Subject: [PATCH 05/18] --- doc/forum/views___40__branches__41___never_get_deleted.mdwn | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn index 618a8cc14a..03dda2241f 100644 --- a/doc/forum/views___40__branches__41___never_get_deleted.mdwn +++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn @@ -12,3 +12,5 @@ Am I doing it wrong? Should I be deleting used view branches on my own? How? thanks for your replies. EDIT: I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this? + +=== git-annex version: 5.20140529-gb71f9bf === From 24c867d443e023b2cafa7896e440eb03fc7269f4 Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q" Date: Tue, 3 Jun 2014 15:46:31 +0000 Subject: [PATCH 06/18] --- doc/forum/views___40__branches__41___never_get_deleted.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn index 03dda2241f..b93c0caf1f 100644 --- a/doc/forum/views___40__branches__41___never_get_deleted.mdwn +++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn @@ -11,6 +11,6 @@ Am I doing it wrong? Should I be deleting used view branches on my own? How? thanks for your replies. -EDIT: I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this? +*EDIT:* I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this? === git-annex version: 5.20140529-gb71f9bf === From 7eb9e740c1aa355cfaefcf0b85932cdf9b2dd96a Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawmYMS6tQ8q9k1fylGyA9Q6fdFzRBotME2Q" Date: Tue, 3 Jun 2014 15:47:04 +0000 Subject: [PATCH 07/18] --- doc/forum/views___40__branches__41___never_get_deleted.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/forum/views___40__branches__41___never_get_deleted.mdwn b/doc/forum/views___40__branches__41___never_get_deleted.mdwn index b93c0caf1f..bba7762dae 100644 --- a/doc/forum/views___40__branches__41___never_get_deleted.mdwn +++ b/doc/forum/views___40__branches__41___never_get_deleted.mdwn @@ -11,6 +11,6 @@ Am I doing it wrong? Should I be deleting used view branches on my own? How? thanks for your replies. -*EDIT:* I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this? +**EDIT:** I just found out that even if I delete view branches with git branch -D "views/attr=_" (which I'm not sure I should be doing), the branches are still checked when doing "git annex unused". That is, "git annex unused" lists "checking..." a whole lot of past views/branches which are not even there anymore (not listed with "git branch"). I also suspect that this is preventing deleted (git-rm) files from being collected from "unused". Is this a problem with my repo? Any way to fix this? -=== git-annex version: 5.20140529-gb71f9bf === +=== git-annex version: **5.20140529-gb71f9bf** === From 2f491497411fb11edfef0e678c1fe8628619dd9f Mon Sep 17 00:00:00 2001 From: erics Date: Tue, 3 Jun 2014 17:49:11 +0000 Subject: [PATCH 08/18] Added a comment --- ...ent_5_be740e4b06d9130ae6afc5783da3c0e0._comment | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment diff --git a/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment new file mode 100644 index 0000000000..32beef4271 --- /dev/null +++ b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_5_be740e4b06d9130ae6afc5783da3c0e0._comment @@ -0,0 +1,14 @@ +[[!comment format=mdwn + username="erics" + ip="76.10.136.8" + subject="comment 5" + date="2014-06-03T17:49:10Z" + content=""" +> It doesn't seem to solve the original use case. + +It doesn't? The OP requested: + +> I would like to hold onto this data if possible, but if you need the space, please delete it + +It looks to me as though my suggestion does just that -- or am I misunderstanding what they asked for? +"""]] From 7374bb61ffe313395d795857922d7de639c4ff09 Mon Sep 17 00:00:00 2001 From: erics Date: Tue, 3 Jun 2014 18:20:50 +0000 Subject: [PATCH 09/18] Added a comment: Metadata vs "drop --relaxed" --- ..._6_79d115f95cec46bb51e7fba078524db1._comment | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment diff --git a/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment new file mode 100644 index 0000000000..6e376e3167 --- /dev/null +++ b/doc/todo/wishlist:___96__git_annex_drop_--relaxed__96__/comment_6_79d115f95cec46bb51e7fba078524db1._comment @@ -0,0 +1,17 @@ +[[!comment format=mdwn + username="erics" + ip="76.10.136.8" + subject="Metadata vs "drop --relaxed"" + date="2014-06-03T18:20:50Z" + content=""" +[This isn't as much about my suggested implementation for \"drop --relaxed\" as about whether the feature is worth providing in the first place. I'm not arguing strongly for it, actually; just continuing the discussion.] + +> I'd be inclinded to instead use the new metadata support. + +I see metadata as more for static attributes of a given file -- this thing is \"a picture\", \"related to project X\", \"from Mary\". Thus, the combination of metadata plus preferred-content settings seems to me more suitable for static preferences (likely ones that implement some kind of policy, however informal); e.g. \"this repo wants pictures but not mp3s\", or \"Mary's stuff but not Alex's\". + +\"drop --relaxed\", on the other hand, would be good for more ad-hoc usage: \"disk space is getting tight; hmm, I'm not using *foo* today, so git-annex, please delete my local copy of *${myrepo}/foo* -- but only as much as you have to, because I'm going to want it again tomorrow\". + +One reason not to want to use metadata and preferred-content settings for such short-term, ad-hoc needs is that you then have to remember to go undo the changes later. That's even worse if you had to add ad-hoc metadata, and now have to go delete it all again. Undoing a \"drop --relaxed\", on the other hand, consists of a simple \"git annex get\". + +"""]] From 31c038da2af2611d6b80bc77232b4cec2d6fbe85 Mon Sep 17 00:00:00 2001 From: gjost Date: Tue, 3 Jun 2014 20:17:56 +0000 Subject: [PATCH 10/18] --- ...g_repositories_to_annex_version__63__.mdwn | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn diff --git a/doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn b/doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn new file mode 100644 index 0000000000..b566fe7d77 --- /dev/null +++ b/doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn @@ -0,0 +1,25 @@ +Is it possible to freeze or peg repositories at a particular version, or at least require confirmation before being upgraded? Is it possible to "downgrade" a repository? + +### Please describe the problem. + +We have a number of repositories on a shared file server. These repositories are accessed by multiple machines. Some of these repositories appear to have gotten upgraded and are now unusable on machines running older versions of git-annex. + +We're getting this message: +[[!format sh """ +densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex status +git-annex: Repository version 5 is not supported. Upgrade git-annex. +"""]] + +The machine experiencing the problem is running Debian Wheezy (Stable). +[[!format sh """ +densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git version +git version 1.7.10.4 +densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex version +git-annex version: 3.20120629 +local repository version: 5 +default repository version: 3 +supported repository versions: 3 +upgrade supported from repository versions: 0 1 2 +"""]] + +I'm guessing that one of the machines with access to this repository was running a newer version of git-annex, and that the repository was upgraded in the course of some action. From 626c07da358a29cf2d41c01b8b200ccb405a5c14 Mon Sep 17 00:00:00 2001 From: gjost Date: Tue, 3 Jun 2014 20:18:40 +0000 Subject: [PATCH 11/18] removed --- ...g_repositories_to_annex_version__63__.mdwn | 25 ------------------- 1 file changed, 25 deletions(-) delete mode 100644 doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn diff --git a/doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn b/doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn deleted file mode 100644 index b566fe7d77..0000000000 --- a/doc/bugs/Possible_to_peg_repositories_to_annex_version__63__.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -Is it possible to freeze or peg repositories at a particular version, or at least require confirmation before being upgraded? Is it possible to "downgrade" a repository? - -### Please describe the problem. - -We have a number of repositories on a shared file server. These repositories are accessed by multiple machines. Some of these repositories appear to have gotten upgraded and are now unusable on machines running older versions of git-annex. - -We're getting this message: -[[!format sh """ -densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex status -git-annex: Repository version 5 is not supported. Upgrade git-annex. -"""]] - -The machine experiencing the problem is running Debian Wheezy (Stable). -[[!format sh """ -densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git version -git version 1.7.10.4 -densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex version -git-annex version: 3.20120629 -local repository version: 5 -default repository version: 3 -supported repository versions: 3 -upgrade supported from repository versions: 0 1 2 -"""]] - -I'm guessing that one of the machines with access to this repository was running a newer version of git-annex, and that the repository was upgraded in the course of some action. From acff2b7392f1914a38cb99fe675d3f4ff8e388d9 Mon Sep 17 00:00:00 2001 From: gjost Date: Tue, 3 Jun 2014 20:20:33 +0000 Subject: [PATCH 12/18] --- .../unwanted_repository_version_upgrades.mdwn | 25 +++++++++++++++++++ 1 file changed, 25 insertions(+) create mode 100644 doc/bugs/unwanted_repository_version_upgrades.mdwn diff --git a/doc/bugs/unwanted_repository_version_upgrades.mdwn b/doc/bugs/unwanted_repository_version_upgrades.mdwn new file mode 100644 index 0000000000..566a941923 --- /dev/null +++ b/doc/bugs/unwanted_repository_version_upgrades.mdwn @@ -0,0 +1,25 @@ +Is it possible to freeze or peg repositories at a particular version, or to prevent automatic repository version upgrades? Is it possible to "downgrade" a repository? + +### Please describe the problem. + +We have a number of repositories on a shared file server. These repositories are accessed by multiple machines. Some of these repositories appear to have gotten upgraded and are now unusable on machines running older versions of git-annex. + +We're getting this message: +[[!format sh """ +densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex status +git-annex: Repository version 5 is not supported. Upgrade git-annex. +"""]] + +The machine experiencing the problem is running Debian Wheezy (Stable). +[[!format sh """ +densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git version +git version 1.7.10.4 +densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex version +git-annex version: 3.20120629 +local repository version: 5 +default repository version: 3 +supported repository versions: 3 +upgrade supported from repository versions: 0 1 2 +"""]] + +I'm guessing that one of the machines with access to this repository was running a newer version of git-annex, and that the repository was upgraded in the course of some action. From cee91dca22ab64e31a7f384932a3cefc2b739092 Mon Sep 17 00:00:00 2001 From: gjost Date: Tue, 3 Jun 2014 20:22:30 +0000 Subject: [PATCH 13/18] --- doc/bugs/unwanted_repository_version_upgrades.mdwn | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/bugs/unwanted_repository_version_upgrades.mdwn b/doc/bugs/unwanted_repository_version_upgrades.mdwn index 566a941923..189550803b 100644 --- a/doc/bugs/unwanted_repository_version_upgrades.mdwn +++ b/doc/bugs/unwanted_repository_version_upgrades.mdwn @@ -6,15 +6,15 @@ We have a number of repositories on a shared file server. These repositories ar We're getting this message: [[!format sh """ -densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex status +user@system:/path/to/repository$ git annex status git-annex: Repository version 5 is not supported. Upgrade git-annex. """]] The machine experiencing the problem is running Debian Wheezy (Stable). [[!format sh """ -densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git version +user@system:/path/to/repository$ git version git version 1.7.10.4 -densho@kinkura:/media/qnfs/kinkura/gold/ddr-janm-1$ git annex version +user@system:/path/to/repository$ git annex version git-annex version: 3.20120629 local repository version: 5 default repository version: 3 From 0d30687bfea40bada09e1f3953e9350ad7cdb395 Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 4 Jun 2014 04:53:36 +0000 Subject: [PATCH 14/18] Added a comment --- .../comment_4_19d32634789a09c1b04e9d3fcde364f7._comment | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment diff --git a/doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment b/doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment new file mode 100644 index 0000000000..66d3c07f8f --- /dev/null +++ b/doc/bugs/5.20140517_fails_to_talk_to_other_5.x_git-annex_remotes/comment_4_19d32634789a09c1b04e9d3fcde364f7._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="https://id.koumbit.net/anarcat" + ip="72.0.72.144" + subject="comment 4" + date="2014-06-04T04:53:36Z" + content=""" +ah. i see. certainly an operator error then. feels like a usability issue now, or i just feel stupid, not sure which. :) +"""]] From 814c20483a41d61355f8190114b05c9d3dbb12bf Mon Sep 17 00:00:00 2001 From: "https://id.koumbit.net/anarcat" Date: Wed, 4 Jun 2014 04:54:53 +0000 Subject: [PATCH 15/18] use the new buglist template --- doc/users/anarcat.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/users/anarcat.mdwn b/doc/users/anarcat.mdwn index 003d412b75..94741aa9fc 100644 --- a/doc/users/anarcat.mdwn +++ b/doc/users/anarcat.mdwn @@ -32,13 +32,13 @@ My bugs ... same. [[!inline pages="bugs/* and !bugs/done and !link(bugs/done) and -link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0]] +link(users/anarcat)" sort=mtime feeds=no actions=yes archive=yes show=0 template=buglist]] Fixed ----- [[!inline pages="bugs/* and !bugs/done and link(bugs/done) and -link(users/anarcat)" feeds=no actions=yes archive=yes show=0]] +link(users/anarcat)" feeds=no actions=yes archive=yes show=0 template=buglist]] Forum posts =========== From 45a4eb72eae7fa002c19e6077b221de5c8356637 Mon Sep 17 00:00:00 2001 From: "https://svario.it/gioele" Date: Wed, 4 Jun 2014 07:03:33 +0000 Subject: [PATCH 16/18] New forum post "Revert to a precedent state in direct mode" --- doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn new file mode 100644 index 0000000000..440e100d1c --- /dev/null +++ b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn @@ -0,0 +1,3 @@ +I have made some mistakes while using `git annex import` in direct mode. Now I see that some files are been erroneously added and there are other problems. I have not yet used `git annex sync`. + +How can I tell git-annex in direct mode (or bare git) to forget about all these changes and revert back to the last known good (pre-import) state? This include removing the few imported files and recreate their links. From f1b13f094a083fc50b690e86b2455836f12d663b Mon Sep 17 00:00:00 2001 From: "https://svario.it/gioele" Date: Wed, 4 Jun 2014 07:04:23 +0000 Subject: [PATCH 17/18] grammar --- doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn index 440e100d1c..08aa843cfd 100644 --- a/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn +++ b/doc/forum/Revert_to_a_precedent_state_in_direct_mode.mdwn @@ -1,3 +1,3 @@ -I have made some mistakes while using `git annex import` in direct mode. Now I see that some files are been erroneously added and there are other problems. I have not yet used `git annex sync`. +I have made some mistakes while using `git annex import` in direct mode. Now I see that some files have been erroneously added and there are other problems. I have not yet used `git annex sync`. -How can I tell git-annex in direct mode (or bare git) to forget about all these changes and revert back to the last known good (pre-import) state? This include removing the few imported files and recreate their links. +How can I tell git-annex in direct mode (or bare git) to forget about all these changes and revert back to the last known good (pre-import) state? This means also removing the few imported files and recreate their links. From bace3004fce8c59e5a02419c2816005587814316 Mon Sep 17 00:00:00 2001 From: "https://svario.it/gioele" Date: Wed, 4 Jun 2014 07:09:01 +0000 Subject: [PATCH 18/18] --- ...aves_stray___96__.tmp__96___files_if_interrupted.mdwn | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn diff --git a/doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn b/doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn new file mode 100644 index 0000000000..658a5a5e1e --- /dev/null +++ b/doc/bugs/import_leaves_stray___96__.tmp__96___files_if_interrupted.mdwn @@ -0,0 +1,9 @@ +### Please describe the problem. + +I have found various `.tmp` files in a directory in which I performed various `git annex import` that failed because the destination disk was full. + +These files should be removed when import detects that its has no more space to proceed and exists. + +### What version of git-annex are you using? On what operating system? + +git-annex 5.20140517.4 in Ubuntu 12.04.