From: Joey Hess Date: Wed, 7 Oct 2020 16:12:53 +0000 (-0400) Subject: renamed some filenames to not end with a period X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~112^2~1 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=2d5036e4408a7ddc964cf6e9314a129a548de5c9;p=git-annex.git renamed some filenames to not end with a period Windows does not allow such filenames, which prevented cloning git-annex on windows. --- diff --git a/doc/bugs/Add_day_to_metadata..mdwn b/doc/bugs/Add_day_to_metadata..mdwn deleted file mode 100644 index 24188a4bcb..0000000000 --- a/doc/bugs/Add_day_to_metadata..mdwn +++ /dev/null @@ -1,15 +0,0 @@ -### Please describe the problem. - -The metadata doesn't include the day for RSS feeds, which is probably only a problem for me as I've built something on top of the metadata to provide an interface for selecting podcasts. - -### Please provide any additional information below. - -The attached patch adds the day field to the metadata. - -There's also a tiny bit extra for stack.yaml which will only affect people who have nix enabled in Stack and will make the build successful for those people. - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -git-annex is awesome, I lean on it heavily nearly every single day. - -> [[merged|done]]. Thanks for the patch! --[[Joey]] diff --git a/doc/bugs/Add_day_to_metadata./comment_1_d46d9f085b7077cc95d71628e45c231d._comment b/doc/bugs/Add_day_to_metadata./comment_1_d46d9f085b7077cc95d71628e45c231d._comment deleted file mode 100644 index ec344a2d6e..0000000000 --- a/doc/bugs/Add_day_to_metadata./comment_1_d46d9f085b7077cc95d71628e45c231d._comment +++ /dev/null @@ -1,64 +0,0 @@ -[[!comment format=mdwn - username="seantparsons" - avatar="http://cdn.libravatar.org/avatar/616fb81847630239dd1ab099138cb685" - subject="Since the attachment doesn't appear to be there, here's the content." - date="2017-10-22T20:32:21Z" - content=""" - diff --git a/Annex/MetaData.hs b/Annex/MetaData.hs - index e22ed05a6..355c5124a 100644 - --- a/Annex/MetaData.hs - +++ b/Annex/MetaData.hs - @@ -60,10 +60,11 @@ dateMetaData :: UTCTime -> MetaData -> MetaData - dateMetaData mtime old = MetaData $ M.fromList $ filter isnew - [ (yearMetaField, S.singleton $ toMetaValue $ show y) - , (monthMetaField, S.singleton $ toMetaValue $ show m) - + , (dayMetaField, S.singleton $ toMetaValue $ show d) - ] - where - isnew (f, _) = S.null (currentMetaDataValues f old) - - (y, m, _d) = toGregorian $ utctDay mtime - + (y, m, d) = toGregorian $ utctDay mtime - - {- Parses field=value, field+=value, field-=value, field?=value -} - parseModMeta :: String -> Either String ModMeta - diff --git a/Annex/MetaData/StandardFields.hs b/Annex/MetaData/StandardFields.hs - index c91b53930..b9ea47e2f 100644 - --- a/Annex/MetaData/StandardFields.hs - +++ b/Annex/MetaData/StandardFields.hs - @@ -9,6 +9,7 @@ module Annex.MetaData.StandardFields ( - tagMetaField, - yearMetaField, - monthMetaField, - + dayMetaField, - lastChangedField, - mkLastChangedField, - isLastChangedField - @@ -27,6 +28,9 @@ yearMetaField = mkMetaFieldUnchecked \"year\" - monthMetaField :: MetaField - monthMetaField = mkMetaFieldUnchecked \"month\" - - +dayMetaField :: MetaField - +dayMetaField = mkMetaFieldUnchecked \"day\" - + - lastChangedField :: MetaField - lastChangedField = mkMetaFieldUnchecked lastchanged - - diff --git a/stack.yaml b/stack.yaml - index d84c4682e..ac601200e 100644 - --- a/stack.yaml - +++ b/stack.yaml - @@ -24,3 +24,11 @@ extra-deps: - explicit-setup-deps: - git-annex: true - resolver: lts-9.9 - +nix: - + packages: - + - ncurses - + - icu - + - libcxx - + - gcc - + - zlib - + - rsync - \ No newline at end of file - -"""]] diff --git a/doc/bugs/Add_day_to_metadata./comment_2_ea15c799c5abfc97eaa20424c15b73a4._comment b/doc/bugs/Add_day_to_metadata./comment_2_ea15c799c5abfc97eaa20424c15b73a4._comment deleted file mode 100644 index 73a5b56063..0000000000 --- a/doc/bugs/Add_day_to_metadata./comment_2_ea15c799c5abfc97eaa20424c15b73a4._comment +++ /dev/null @@ -1,12 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2017-11-08T18:51:20Z" - content=""" -Unfortunately the added nix section broke the i386-ancient build, -which uses stack 1.0.4. That version of stack complains: - -Executable named nix-shell not found on path: ["/usr/local/sbin","/usr/local/bin","/sbin","/bin","/usr/sbin","/usr/bin"] - -So, I've reverted the addition of that section. -"""]] diff --git a/doc/bugs/Add_day_to_metadata.mdwn b/doc/bugs/Add_day_to_metadata.mdwn new file mode 100644 index 0000000000..24188a4bcb --- /dev/null +++ b/doc/bugs/Add_day_to_metadata.mdwn @@ -0,0 +1,15 @@ +### Please describe the problem. + +The metadata doesn't include the day for RSS feeds, which is probably only a problem for me as I've built something on top of the metadata to provide an interface for selecting podcasts. + +### Please provide any additional information below. + +The attached patch adds the day field to the metadata. + +There's also a tiny bit extra for stack.yaml which will only affect people who have nix enabled in Stack and will make the build successful for those people. + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +git-annex is awesome, I lean on it heavily nearly every single day. + +> [[merged|done]]. Thanks for the patch! --[[Joey]] diff --git a/doc/bugs/Add_day_to_metadata/comment_1_d46d9f085b7077cc95d71628e45c231d._comment b/doc/bugs/Add_day_to_metadata/comment_1_d46d9f085b7077cc95d71628e45c231d._comment new file mode 100644 index 0000000000..ec344a2d6e --- /dev/null +++ b/doc/bugs/Add_day_to_metadata/comment_1_d46d9f085b7077cc95d71628e45c231d._comment @@ -0,0 +1,64 @@ +[[!comment format=mdwn + username="seantparsons" + avatar="http://cdn.libravatar.org/avatar/616fb81847630239dd1ab099138cb685" + subject="Since the attachment doesn't appear to be there, here's the content." + date="2017-10-22T20:32:21Z" + content=""" + diff --git a/Annex/MetaData.hs b/Annex/MetaData.hs + index e22ed05a6..355c5124a 100644 + --- a/Annex/MetaData.hs + +++ b/Annex/MetaData.hs + @@ -60,10 +60,11 @@ dateMetaData :: UTCTime -> MetaData -> MetaData + dateMetaData mtime old = MetaData $ M.fromList $ filter isnew + [ (yearMetaField, S.singleton $ toMetaValue $ show y) + , (monthMetaField, S.singleton $ toMetaValue $ show m) + + , (dayMetaField, S.singleton $ toMetaValue $ show d) + ] + where + isnew (f, _) = S.null (currentMetaDataValues f old) + - (y, m, _d) = toGregorian $ utctDay mtime + + (y, m, d) = toGregorian $ utctDay mtime + + {- Parses field=value, field+=value, field-=value, field?=value -} + parseModMeta :: String -> Either String ModMeta + diff --git a/Annex/MetaData/StandardFields.hs b/Annex/MetaData/StandardFields.hs + index c91b53930..b9ea47e2f 100644 + --- a/Annex/MetaData/StandardFields.hs + +++ b/Annex/MetaData/StandardFields.hs + @@ -9,6 +9,7 @@ module Annex.MetaData.StandardFields ( + tagMetaField, + yearMetaField, + monthMetaField, + + dayMetaField, + lastChangedField, + mkLastChangedField, + isLastChangedField + @@ -27,6 +28,9 @@ yearMetaField = mkMetaFieldUnchecked \"year\" + monthMetaField :: MetaField + monthMetaField = mkMetaFieldUnchecked \"month\" + + +dayMetaField :: MetaField + +dayMetaField = mkMetaFieldUnchecked \"day\" + + + lastChangedField :: MetaField + lastChangedField = mkMetaFieldUnchecked lastchanged + + diff --git a/stack.yaml b/stack.yaml + index d84c4682e..ac601200e 100644 + --- a/stack.yaml + +++ b/stack.yaml + @@ -24,3 +24,11 @@ extra-deps: + explicit-setup-deps: + git-annex: true + resolver: lts-9.9 + +nix: + + packages: + + - ncurses + + - icu + + - libcxx + + - gcc + + - zlib + + - rsync + \ No newline at end of file + +"""]] diff --git a/doc/bugs/Add_day_to_metadata/comment_2_ea15c799c5abfc97eaa20424c15b73a4._comment b/doc/bugs/Add_day_to_metadata/comment_2_ea15c799c5abfc97eaa20424c15b73a4._comment new file mode 100644 index 0000000000..73a5b56063 --- /dev/null +++ b/doc/bugs/Add_day_to_metadata/comment_2_ea15c799c5abfc97eaa20424c15b73a4._comment @@ -0,0 +1,12 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2017-11-08T18:51:20Z" + content=""" +Unfortunately the added nix section broke the i386-ancient build, +which uses stack 1.0.4. That version of stack complains: + +Executable named nix-shell not found on path: ["/usr/local/sbin","/usr/local/bin","/sbin","/bin","/usr/sbin","/usr/bin"] + +So, I've reverted the addition of that section. +"""]] diff --git a/doc/bugs/Error_cloning_repository_on_Windows.mdwn b/doc/bugs/Error_cloning_repository_on_Windows.mdwn index d250db8d13..6b41f908d7 100644 --- a/doc/bugs/Error_cloning_repository_on_Windows.mdwn +++ b/doc/bugs/Error_cloning_repository_on_Windows.mdwn @@ -16,3 +16,5 @@ Because of this, developing and building on Windows is harder and more needlessl ### What steps will reproduce the problem? Cloning the git-annex repository on Windows 7 — or any other Windows, I believe. + +> [[fixed|done]] --[[Joey]] diff --git a/doc/bugs/Error_cloning_repository_on_Windows/comment_1_3c95fbb637e8043f988822069518fd3a._comment b/doc/bugs/Error_cloning_repository_on_Windows/comment_1_3c95fbb637e8043f988822069518fd3a._comment new file mode 100644 index 0000000000..06f71efba5 --- /dev/null +++ b/doc/bugs/Error_cloning_repository_on_Windows/comment_1_3c95fbb637e8043f988822069518fd3a._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2020-10-07T16:11:23Z" + content=""" +Thanks for reporting that. We used to have problems with : getting into +filenames in the website, fixed that, so I've gone ahead and fixed this +too, including (I hope) configuring it to reject a trailing period. +"""]] diff --git a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed..mdwn b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed..mdwn deleted file mode 100644 index bf2972257b..0000000000 --- a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed..mdwn +++ /dev/null @@ -1,37 +0,0 @@ -### Please describe the problem. - -As documented in [[git-annex-matching-options]], `--copies` accepts `trustlevel` or `groupname` in the following format: - -* `--copies=trustlevel:number` -* `--copies=groupname:number` - -This is ambiguous in the unlikely case where a user might come up with the idea to create a group called `trusted`, `semitrusted` or `untrusted` (`remote..annex-trustlevel`). It should thereby not be allowed to use such special groups. - -### What steps will reproduce the problem? - - -[[!format sh """ -## In an annex repo: - -git annex group here trusted - -## What does this command do now? -## For reference, it interprets it as `--copies=trustlevel:number` -git annex find --copies=trusted:1 - -"""]] - -### What version of git-annex are you using? On what operating system? - - git-annex version: 6.20180509 - build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite - dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 - key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL - remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external - operating system: linux x86_64 - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -Yes! Thanks so much for your work! - -> Closing per comments. [[done]] --[[Joey]] diff --git a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed./comment_1_b4ba41b6e0e611d90ddda92bbe991266._comment b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed./comment_1_b4ba41b6e0e611d90ddda92bbe991266._comment deleted file mode 100644 index 4bd9247927..0000000000 --- a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed./comment_1_b4ba41b6e0e611d90ddda92bbe991266._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2018-06-04T16:06:57Z" - content=""" -Thanks for pointing out this ambiguity, which I don't remember having -ever considered. - -The code for this does look for the name of a trust level first, -and only a group name if it's not a trust level. So, adding a group -with a colliding name will never change the behavior of such a command -or preferred content expression. - -The only problem then would be that you couldn't match -on a group by that name. But if you run into that problem, -you can simply rename your group. - -So I don't think that git-annex needs a sanity check, really. - -(I have added a comment in the code to make clear that the order of -parsing this does matter.) -"""]] diff --git a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed./comment_2_73b2d20a793a8a17cf0a3d593b3b4ed4._comment b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed./comment_2_73b2d20a793a8a17cf0a3d593b3b4ed4._comment deleted file mode 100644 index c9b6f38a71..0000000000 --- a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed./comment_2_73b2d20a793a8a17cf0a3d593b3b4ed4._comment +++ /dev/null @@ -1,8 +0,0 @@ -[[!comment format=mdwn - username="ypid" - avatar="http://cdn.libravatar.org/avatar/4286841cddc77176758dde874afe9a3a" - subject="comment 2" - date="2018-06-04T19:42:30Z" - content=""" -Works for me, thanks. I also think this is not a real issue, I just noticed the edge case. -"""]] diff --git a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed.mdwn b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed.mdwn new file mode 100644 index 0000000000..bf2972257b --- /dev/null +++ b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed.mdwn @@ -0,0 +1,37 @@ +### Please describe the problem. + +As documented in [[git-annex-matching-options]], `--copies` accepts `trustlevel` or `groupname` in the following format: + +* `--copies=trustlevel:number` +* `--copies=groupname:number` + +This is ambiguous in the unlikely case where a user might come up with the idea to create a group called `trusted`, `semitrusted` or `untrusted` (`remote..annex-trustlevel`). It should thereby not be allowed to use such special groups. + +### What steps will reproduce the problem? + + +[[!format sh """ +## In an annex repo: + +git annex group here trusted + +## What does this command do now? +## For reference, it interprets it as `--copies=trustlevel:number` +git annex find --copies=trusted:1 + +"""]] + +### What version of git-annex are you using? On what operating system? + + git-annex version: 6.20180509 + build flags: Assistant Webapp Pairing S3(multipartupload)(storageclasses) WebDAV Inotify DBus DesktopNotify ConcurrentOutput TorrentParser MagicMime Feeds Testsuite + dependency versions: aws-0.14.1 bloomfilter-2.0.1.0 cryptonite-0.20 DAV-1.3.1 feed-0.3.11.1 ghc-8.0.1 http-client-0.4.31.1 persistent-sqlite-2.6 torrent-10000.0.0 uuid-1.3.12 yesod-1.4.3 + key/value backends: SHA256E SHA256 SHA512E SHA512 SHA224E SHA224 SHA384E SHA384 SHA3_256E SHA3_256 SHA3_512E SHA3_512 SHA3_224E SHA3_224 SHA3_384E SHA3_384 SKEIN256E SKEIN256 SKEIN512E SKEIN512 SHA1E SHA1 MD5E MD5 WORM URL + remote types: git gcrypt p2p S3 bup directory rsync web bittorrent webdav adb tahoe glacier ddar hook external + operating system: linux x86_64 + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +Yes! Thanks so much for your work! + +> Closing per comments. [[done]] --[[Joey]] diff --git a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed/comment_1_b4ba41b6e0e611d90ddda92bbe991266._comment b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed/comment_1_b4ba41b6e0e611d90ddda92bbe991266._comment new file mode 100644 index 0000000000..4bd9247927 --- /dev/null +++ b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed/comment_1_b4ba41b6e0e611d90ddda92bbe991266._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2018-06-04T16:06:57Z" + content=""" +Thanks for pointing out this ambiguity, which I don't remember having +ever considered. + +The code for this does look for the name of a trust level first, +and only a group name if it's not a trust level. So, adding a group +with a colliding name will never change the behavior of such a command +or preferred content expression. + +The only problem then would be that you couldn't match +on a group by that name. But if you run into that problem, +you can simply rename your group. + +So I don't think that git-annex needs a sanity check, really. + +(I have added a comment in the code to make clear that the order of +parsing this does matter.) +"""]] diff --git a/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed/comment_2_73b2d20a793a8a17cf0a3d593b3b4ed4._comment b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed/comment_2_73b2d20a793a8a17cf0a3d593b3b4ed4._comment new file mode 100644 index 0000000000..c9b6f38a71 --- /dev/null +++ b/doc/bugs/Missing_sanity_check_of_group_names._Special_group_names_should_not_be_allowed/comment_2_73b2d20a793a8a17cf0a3d593b3b4ed4._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="ypid" + avatar="http://cdn.libravatar.org/avatar/4286841cddc77176758dde874afe9a3a" + subject="comment 2" + date="2018-06-04T19:42:30Z" + content=""" +Works for me, thanks. I also think this is not a real issue, I just noticed the edge case. +"""]] diff --git a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting..mdwn b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting..mdwn deleted file mode 100644 index eb1c1d6465..0000000000 --- a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting..mdwn +++ /dev/null @@ -1,45 +0,0 @@ -### Please describe the problem. -After month of flawless operations, a gcrypted special (rsync) remote has suddenly stopped working. Below is what since happens on every git annex sync. - - ... - push rsync.net - gcrypt: Repository not found: ssh://usw-a123.rsync.net/data1/home/XXXX/annex/files - gcrypt: ..but repository ID is set. Aborting. - -At the file system level, the remote appears to be intact. - - foo@bar:~$ ssh usw-a123.rsync.net ls -lah annex/files/ - total 175 - drwxr-xr-x 8 XXXX XXXX 11B Sep 8 17:23 . - drwxr-xr-x 3 XXXX XXXX 3B Mar 25 11:42 .. - -rw-r--r-- 1 XXXX XXXX 23B Mar 22 18:25 HEAD - drwxr-xr-x 3 XXXX XXXX 3B Mar 22 18:26 annex - drwxr-xr-x 2 XXXX XXXX 2B Mar 22 18:25 branches - -rw-r--r-- 1 XXXX XXXX 143B Mar 30 10:12 config - -rw-r--r-- 1 XXXX XXXX 73B Mar 22 18:25 description - drwxr-xr-x 2 XXXX XXXX 12B Mar 22 18:25 hooks - drwxr-xr-x 2 XXXX XXXX 3B Mar 22 18:25 info - drwxr-xr-x 255 XXXX XXXX 255B Sep 8 04:56 objects - drwxr-xr-x 4 XXXX XXXX 4B Mar 22 18:25 refs - - -### What steps will reproduce the problem? -Unknown - -### What version of git-annex are you using? On what operating system? -* git-annex-standalone 6.20180807+git230-gaa291acfe-1~ndall+1 amd64 (Neurodebian) -* Ubuntu 18.04 - -### Please provide any additional information below. - -[[!format sh """ -# If you can, paste a complete transcript of the problem occurring here. -# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log - - -# End of transcript or log. -"""]] - -### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) - -I am a vocal advocate of git-annex. :-) diff --git a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting./comment_1_ec28718db57922b7d0c01f3ef672e6d4._comment b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting./comment_1_ec28718db57922b7d0c01f3ef672e6d4._comment deleted file mode 100644 index de25721ddc..0000000000 --- a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting./comment_1_ec28718db57922b7d0c01f3ef672e6d4._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="git-annex.branchable.com@79d6855760f61f7fbe0a401b45d8c791ef49b500" - nickname="git-annex.branchable.com" - avatar="http://cdn.libravatar.org/avatar/4bf61f9feda20e8b4fc09d52ee48af39" - subject="comment 1" - date="2018-09-14T16:42:59Z" - content=""" -It turns out that rsync.net silently changed the (absolute) path to my user's home directory and the path in .git/config was thus incorrect. -"""]] diff --git a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting./comment_2_e4d97ac757e7da09c9c23f74177991ae._comment b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting./comment_2_e4d97ac757e7da09c9c23f74177991ae._comment deleted file mode 100644 index c103ce3842..0000000000 --- a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting./comment_2_e4d97ac757e7da09c9c23f74177991ae._comment +++ /dev/null @@ -1,10 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 2""" - date="2018-09-14T16:52:56Z" - content=""" -This is gcrypt displaying an error message, not git-annex. - -Do you have any indication it's somehow a git-annex bug? The obvious guess -would be that it's a gcrypt bug. -"""]] diff --git a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting.mdwn b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting.mdwn new file mode 100644 index 0000000000..eb1c1d6465 --- /dev/null +++ b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting.mdwn @@ -0,0 +1,45 @@ +### Please describe the problem. +After month of flawless operations, a gcrypted special (rsync) remote has suddenly stopped working. Below is what since happens on every git annex sync. + + ... + push rsync.net + gcrypt: Repository not found: ssh://usw-a123.rsync.net/data1/home/XXXX/annex/files + gcrypt: ..but repository ID is set. Aborting. + +At the file system level, the remote appears to be intact. + + foo@bar:~$ ssh usw-a123.rsync.net ls -lah annex/files/ + total 175 + drwxr-xr-x 8 XXXX XXXX 11B Sep 8 17:23 . + drwxr-xr-x 3 XXXX XXXX 3B Mar 25 11:42 .. + -rw-r--r-- 1 XXXX XXXX 23B Mar 22 18:25 HEAD + drwxr-xr-x 3 XXXX XXXX 3B Mar 22 18:26 annex + drwxr-xr-x 2 XXXX XXXX 2B Mar 22 18:25 branches + -rw-r--r-- 1 XXXX XXXX 143B Mar 30 10:12 config + -rw-r--r-- 1 XXXX XXXX 73B Mar 22 18:25 description + drwxr-xr-x 2 XXXX XXXX 12B Mar 22 18:25 hooks + drwxr-xr-x 2 XXXX XXXX 3B Mar 22 18:25 info + drwxr-xr-x 255 XXXX XXXX 255B Sep 8 04:56 objects + drwxr-xr-x 4 XXXX XXXX 4B Mar 22 18:25 refs + + +### What steps will reproduce the problem? +Unknown + +### What version of git-annex are you using? On what operating system? +* git-annex-standalone 6.20180807+git230-gaa291acfe-1~ndall+1 amd64 (Neurodebian) +* Ubuntu 18.04 + +### Please provide any additional information below. + +[[!format sh """ +# If you can, paste a complete transcript of the problem occurring here. +# If the problem is with the git-annex assistant, paste in .git/annex/daemon.log + + +# End of transcript or log. +"""]] + +### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders) + +I am a vocal advocate of git-annex. :-) diff --git a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting/comment_1_ec28718db57922b7d0c01f3ef672e6d4._comment b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting/comment_1_ec28718db57922b7d0c01f3ef672e6d4._comment new file mode 100644 index 0000000000..de25721ddc --- /dev/null +++ b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting/comment_1_ec28718db57922b7d0c01f3ef672e6d4._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="git-annex.branchable.com@79d6855760f61f7fbe0a401b45d8c791ef49b500" + nickname="git-annex.branchable.com" + avatar="http://cdn.libravatar.org/avatar/4bf61f9feda20e8b4fc09d52ee48af39" + subject="comment 1" + date="2018-09-14T16:42:59Z" + content=""" +It turns out that rsync.net silently changed the (absolute) path to my user's home directory and the path in .git/config was thus incorrect. +"""]] diff --git a/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting/comment_2_e4d97ac757e7da09c9c23f74177991ae._comment b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting/comment_2_e4d97ac757e7da09c9c23f74177991ae._comment new file mode 100644 index 0000000000..c103ce3842 --- /dev/null +++ b/doc/bugs/gcrypt__58___..but_repository_ID_is_set._Aborting/comment_2_e4d97ac757e7da09c9c23f74177991ae._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 2""" + date="2018-09-14T16:52:56Z" + content=""" +This is gcrypt displaying an error message, not git-annex. + +Do you have any indication it's somehow a git-annex bug? The obvious guess +would be that it's a gcrypt bug. +"""]] diff --git a/doc/forum/Dead_repo_content_is_not_considered_unused..mdwn b/doc/forum/Dead_repo_content_is_not_considered_unused..mdwn deleted file mode 100644 index 87a977592d..0000000000 --- a/doc/forum/Dead_repo_content_is_not_considered_unused..mdwn +++ /dev/null @@ -1,15 +0,0 @@ -I can't get content referenced in a dead repo to be considered unused. - -Setup: - -1. Make repo A and B, connect them -2. Add file to A, copy to B, sync -3. Sync B -4. Mark A dead -5. Delete symlink from B -6. Run git-annex forget --drop-dead on B -7. Run git-annex unused on B - -The file does not appear as unused. Am I doing something wrong or is this genuinely impossible? - -I can understand the reasons for not wanting it to work this way in case the dead repo had important files, but what this means is files I genuinely want to drop will never be considered unused if they existed in the dead repo. This could create an issue for me if I lose a repo in one of my very large annexes, because that could mean gigs of wasted space. I rely on unused to safely drop content because the drop command may remove files that are still referenced somewhere else (duplicate symlinks). diff --git a/doc/forum/Dead_repo_content_is_not_considered_unused./comment_1_e78552e939891b950a8352e4e3bdff92._comment b/doc/forum/Dead_repo_content_is_not_considered_unused./comment_1_e78552e939891b950a8352e4e3bdff92._comment deleted file mode 100644 index ec066be266..0000000000 --- a/doc/forum/Dead_repo_content_is_not_considered_unused./comment_1_e78552e939891b950a8352e4e3bdff92._comment +++ /dev/null @@ -1,22 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2020-06-30T14:45:06Z" - content=""" -A file is not considered unused until there are no git branches that still -refer to that file. - -When you delete the symlink in step 5, you don't say -you commit it, so the master branch still refers to the file; it's not -unused. - -Also, you have A as a remote of B still. So git still has a tracking -branch, remotes/A/master, that still contains the file. So the file -is still considered in use because of that. - -I think you'll probably also have a synced/master branch that contains -the file too, at least until you sync with some other repository, or delete -the branch. Arguably that's an implementation detail of git-annex and perhaps -it should not consider those branches when checking for branches -that contain a file. -"""]] diff --git a/doc/forum/Dead_repo_content_is_not_considered_unused.mdwn b/doc/forum/Dead_repo_content_is_not_considered_unused.mdwn new file mode 100644 index 0000000000..87a977592d --- /dev/null +++ b/doc/forum/Dead_repo_content_is_not_considered_unused.mdwn @@ -0,0 +1,15 @@ +I can't get content referenced in a dead repo to be considered unused. + +Setup: + +1. Make repo A and B, connect them +2. Add file to A, copy to B, sync +3. Sync B +4. Mark A dead +5. Delete symlink from B +6. Run git-annex forget --drop-dead on B +7. Run git-annex unused on B + +The file does not appear as unused. Am I doing something wrong or is this genuinely impossible? + +I can understand the reasons for not wanting it to work this way in case the dead repo had important files, but what this means is files I genuinely want to drop will never be considered unused if they existed in the dead repo. This could create an issue for me if I lose a repo in one of my very large annexes, because that could mean gigs of wasted space. I rely on unused to safely drop content because the drop command may remove files that are still referenced somewhere else (duplicate symlinks). diff --git a/doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment b/doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment new file mode 100644 index 0000000000..ec066be266 --- /dev/null +++ b/doc/forum/Dead_repo_content_is_not_considered_unused/comment_1_e78552e939891b950a8352e4e3bdff92._comment @@ -0,0 +1,22 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2020-06-30T14:45:06Z" + content=""" +A file is not considered unused until there are no git branches that still +refer to that file. + +When you delete the symlink in step 5, you don't say +you commit it, so the master branch still refers to the file; it's not +unused. + +Also, you have A as a remote of B still. So git still has a tracking +branch, remotes/A/master, that still contains the file. So the file +is still considered in use because of that. + +I think you'll probably also have a synced/master branch that contains +the file too, at least until you sync with some other repository, or delete +the branch. Arguably that's an implementation detail of git-annex and perhaps +it should not consider those branches when checking for branches +that contain a file. +"""]] diff --git a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue..mdwn b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue..mdwn deleted file mode 100644 index ee024eca43..0000000000 --- a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue..mdwn +++ /dev/null @@ -1 +0,0 @@ -I would like to make some thing. On windows one repo (R1) with files for work. On linux server the other (R2) is for syncing and the third (R3) on linux is for backup with bup. Is it any way to run remote backup command on R2 from R1 but not always when i sync them - only when i send special command? I am looking simple native solution avoiding cygwin or third scripts. Thanks. diff --git a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue./comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue./comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment deleted file mode 100644 index 3a5bc1c0d8..0000000000 --- a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue./comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment +++ /dev/null @@ -1,9 +0,0 @@ -[[!comment format=mdwn - username="joey" - subject="""comment 1""" - date="2016-07-12T18:34:13Z" - content=""" -Well, you can ssh into the linux box and cd to R2 and run `git annex sync ----content` and that should cause it to download any new files that it can -(if it can contact R1), and send them along to R3. -"""]] diff --git a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn new file mode 100644 index 0000000000..ee024eca43 --- /dev/null +++ b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue.mdwn @@ -0,0 +1 @@ +I would like to make some thing. On windows one repo (R1) with files for work. On linux server the other (R2) is for syncing and the third (R3) on linux is for backup with bup. Is it any way to run remote backup command on R2 from R1 but not always when i sync them - only when i send special command? I am looking simple native solution avoiding cygwin or third scripts. Thanks. diff --git a/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment new file mode 100644 index 0000000000..3a5bc1c0d8 --- /dev/null +++ b/doc/forum/Git_annex__44___bup__44___windows_and_remote_linux_issue/comment_1_c9239f9c67b2441ab0e1ac42c53db531._comment @@ -0,0 +1,9 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2016-07-12T18:34:13Z" + content=""" +Well, you can ssh into the linux box and cd to R2 and run `git annex sync +---content` and that should cause it to download any new files that it can +(if it can contact R1), and send them along to R3. +"""]]