+++ /dev/null
-### 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]]
+++ /dev/null
-[[!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
-
-"""]]
+++ /dev/null
-[[!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.
-"""]]
--- /dev/null
+### 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]]
--- /dev/null
+[[!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
+
+"""]]
--- /dev/null
+[[!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.
+"""]]
### What steps will reproduce the problem?
Cloning the git-annex repository on Windows 7 — or any other Windows, I believe.
+
+> [[fixed|done]] --[[Joey]]
--- /dev/null
+[[!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.
+"""]]
+++ /dev/null
-### 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.<name>.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]]
+++ /dev/null
-[[!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.)
-"""]]
+++ /dev/null
-[[!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.
-"""]]
--- /dev/null
+### 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.<name>.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]]
--- /dev/null
+[[!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.)
+"""]]
--- /dev/null
+[[!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.
+"""]]
+++ /dev/null
-### 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. :-)
+++ /dev/null
-[[!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.
-"""]]
+++ /dev/null
-[[!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.
-"""]]
--- /dev/null
+### 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. :-)
--- /dev/null
+[[!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.
+"""]]
--- /dev/null
+[[!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.
+"""]]
+++ /dev/null
-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).
+++ /dev/null
-[[!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.
-"""]]
--- /dev/null
+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).
--- /dev/null
+[[!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.
+"""]]
+++ /dev/null
-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.
+++ /dev/null
-[[!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.
-"""]]
--- /dev/null
+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.
--- /dev/null
+[[!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.
+"""]]
projects / git-annex.git / commitdiff