From f970490750fd5b71009b7575b19247a504eaca36 Mon Sep 17 00:00:00 2001 From: ExGen Date: Fri, 8 Apr 2016 21:03:15 +0000 Subject: [PATCH 1/6] Added a comment: comment 3^^ --- ...comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment new file mode 100644 index 0000000000..3140fee364 --- /dev/null +++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_3_8a19ca100d44ab8131e40932f1bcdf29._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="ExGen" + subject="comment 3^^" + date="2016-04-08T21:03:15Z" + content=""" +It's 6.20160401-g083dd8f, Sorry for the delay. +And btw my v6 repo is not in adjusted mode. But I think adjusted mode has the same problem too. + + +"""]] From 196547ec8dd1de8db40e1cbef4190f4bec976cf2 Mon Sep 17 00:00:00 2001 From: ExGen Date: Fri, 8 Apr 2016 22:00:33 +0000 Subject: [PATCH 2/6] Added a comment: comment 4 --- ..._b70fa3da7e776a6cd6d8467df30839c9._comment | 35 +++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment diff --git a/doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment b/doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment new file mode 100644 index 0000000000..a6d7ebecdc --- /dev/null +++ b/doc/bugs/Windows__58___git_annex_get_failed/comment_4_b70fa3da7e776a6cd6d8467df30839c9._comment @@ -0,0 +1,35 @@ +[[!comment format=mdwn + username="ExGen" + subject="comment 4" + date="2016-04-08T22:00:33Z" + content=""" +I pulled and checked 6.20160408-gf970490.
+There are several problems now:
+ +1. When I `sync` on a new repo it `get`s all the files
+2. `drop` doesn't drop the file +3. `lock` doesn't work
+4. I don't know if the problem with `get` really fixed because it isn't needed + +Btw, look at my comment on /todo/smudge (maybe put on a wrong page)
+I think using hardlinks on windows can fix many problems here ( adjusted/direct mode which I hate :)) )
+And it should need little work as tools already accept it on windows + +I'll put all the commands needed to reproduce the problem: + + cd D:/annex + git init + git annex init \"laptop\" + git annex upgrade + git add . + git commit -a -m \"First\" + git annex lock + git annex sync + + cd H:/annex + git init + git annex init \"usb\" + git annex upgrade + git remote add laptop D:/annex + git annex sync +"""]] From d1dd9b5a4beb4a34b906e5ce8f703350a19c6f43 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Sat, 9 Apr 2016 00:41:41 -0400 Subject: [PATCH 3/6] respond --- ...3_d46183e53b1e6293681efadec9b46c6b._comment | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment diff --git a/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment new file mode 100644 index 0000000000..b21e9e21db --- /dev/null +++ b/doc/todo/dumb__44___unsafe__44___human-readable_backend/comment_3_d46183e53b1e6293681efadec9b46c6b._comment @@ -0,0 +1,18 @@ +[[!comment format=mdwn + username="anarcat" + subject="""comment 3""" + date="2016-04-09T04:39:11Z" + content=""" +What about having a direct more in an external work tree? + +I could have my .git directory in some local directory (say +`~/.git-annex/remote-mp3.git`) and the actual files on the device (say +`/media/anarcat/mounted/mp3`). + +I know that there are many possible names for a single key, but isn't +that a problem for direct mode as well? + +And I know it's a poney... I keep on asking for poneys here, but +poneys are great, and actually quite useful and even friendly animals +if you can use and take care of them correctly. :) +"""]] From d89161e13f5d10ac8edd78d2bf16dbdc565f8e1e Mon Sep 17 00:00:00 2001 From: "0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" <0xloem@web> Date: Sat, 9 Apr 2016 10:37:23 +0000 Subject: [PATCH 4/6] Added a comment: freenet special remote --- ...mment_4_469c952a131d2aac45615afb3a69d10c._comment | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment diff --git a/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment new file mode 100644 index 0000000000..4fd2ddc210 --- /dev/null +++ b/doc/todo/wishlist__58___spec.remotes_for_other_peer_network_data_stores___40__gnunet__44___freenet__41__/comment_4_469c952a131d2aac45615afb3a69d10c._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="0xloem@0bd8a79a57e4f0dcade8fc81d162c37eae4d6730" + nickname="0xloem" + subject="freenet special remote" + date="2016-04-09T10:37:22Z" + content=""" +I've gotten derailed, but in case somebody else is interested for now, I've started a freenet special remote at https://github.com/xloem/gitlakepy . Also includes beginnings of a generic python class for special remotes in the same scriptfile. + +SETSTATE is helpful but doesn't allow for any form of hashing the file offline, to ensure the hash matches. It means there could be data corruption uploading the file and there would be no way to check that the hash matched the local data. It would be nice to provide new hashing backends as well, perhaps then somebody could make a multi-hash which stores different hashes side-by-side to resolve such paranoia. + +I guess for now the right way to do these things is to add the new capabilities straight to the internals of git-annex, but learning haskell is an adventure when time is a constraint. +"""]] From c363bea6521e8d23c64591faa841cdbbfbb383e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Sat, 9 Apr 2016 10:40:46 -0400 Subject: [PATCH 5/6] attack the manpage problem --- doc/todo/cleaner_hack_for_man_pages.mdwn | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) create mode 100644 doc/todo/cleaner_hack_for_man_pages.mdwn diff --git a/doc/todo/cleaner_hack_for_man_pages.mdwn b/doc/todo/cleaner_hack_for_man_pages.mdwn new file mode 100644 index 0000000000..5adce386d1 --- /dev/null +++ b/doc/todo/cleaner_hack_for_man_pages.mdwn @@ -0,0 +1,16 @@ +In recent history, we have realized that the small Perl script that +generates the man pages from Markdown is fairly limited. + +Two approaches have been considered: + +* go-md2man +* pandoc + +Here is how pandoc does it: + + $ pandoc -f markdown -t man doc/git-annex-shell.mdwn | pastebinit + http://paste.debian.net/424341/ + + +Both initially fail at setting a proper `.TH` line on top, but +otherwise seem to work more or less correctly. --[[anarcat]] From a5158baa8953d71cb432375af0333c6a61d7f62c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= Date: Sat, 9 Apr 2016 11:04:42 -0400 Subject: [PATCH 6/6] possible fix for markdown generation with pandoc --- doc/todo/cleaner_hack_for_man_pages.mdwn | 61 +++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) diff --git a/doc/todo/cleaner_hack_for_man_pages.mdwn b/doc/todo/cleaner_hack_for_man_pages.mdwn index 5adce386d1..d54b3fc2a3 100644 --- a/doc/todo/cleaner_hack_for_man_pages.mdwn +++ b/doc/todo/cleaner_hack_for_man_pages.mdwn @@ -11,6 +11,65 @@ Here is how pandoc does it: $ pandoc -f markdown -t man doc/git-annex-shell.mdwn | pastebinit http://paste.debian.net/424341/ - Both initially fail at setting a proper `.TH` line on top, but otherwise seem to work more or less correctly. --[[anarcat]] + +Okay, update: the above commandline was incorrect for some reason. The +proper incantation is: + + pandoc -s -t man doc/git-annex-shell.mdwn -o git-annex-shell.1 + +For example: + + $ pandoc -s -t man doc/git-annex-shell.mdwn | man -l - | pastebinit + http://paste.debian.net/430630/ + +So by default, there is no title or section header, which is, if you +ask me a little stupid: pandoc could guess a little better and parse +the `.SH NAME` section. + +The workaround for this is to add Pandoc metadata either to the file, +for example: + +[[!format diff """ +diff --git a/doc/git-annex-shell.mdwn b/doc/git-annex-shell.mdwn +index 9b3d126..13f64ae 100644 +--- a/doc/git-annex-shell.mdwn ++++ b/doc/git-annex-shell.mdwn +@@ -1,3 +1,6 @@ ++% git-annex-shell(1) Git-annex manual | Version 5 ++% Joey Hess ++ + # NAME + + git-annex-shell - Restricted login shell for git-annex only SSH access +"""]] + +But Ikiwiki is likely to barf on such comments, so it's probably +preferable to pass those parameters at build time: + + $ pandoc -s -V title="git-annex-shell" -V section=1 -t man doc/git-annex-shell.mdwn | man -l - | pastebinit + http://paste.debian.net/430632/ + +Looks better already! But we can improve on that even more! + + $ pandoc -s -V title="git-annex-shell" -V section=1 \ + -V header="Git Annex manual" -V footer="Version 5.xxx" \ + -t man doc/git-annex-shell.mdwn | man -l - | pastebinit + http://paste.debian.net/430633/ + +Much better. And the version can probably be passed in from the build +system (or that footer can just be dropped). + +So a more complete patch would involve fixing the build system to use +(and depend on!) pandoc then remove the pesky warnings at the bottom +of all Markdown files. + +More investigation would probably be necessary to check the resulting +man pages for syntax errors. For example, the above rendering, in the +`SEE ALSO` section, has `[git-annex] (1)` instead of +`git-annex(1)`, since Pandoc doesn't know about ikiwiki links. Maybe +some pre-processing would be necessary there? :/ It sure is useful to +have those links working in the web version! + +I hope that helps regardless.