Merge branch 'master' of ssh://git-annex.branchable.com

7 files changed, 208 insertions, 0 deletions

diff --git a/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn
new file mode 100644
index 000000000..83fedbb1e
--- /dev/null
+++ b/doc/bugs/Assistant_does_not_update_adjusted_branch.mdwn
@@ -0,0 +1,90 @@
+### Please describe the problem.
+
+When using the assistant to synchronize several annex repositories, changes are not correctly or not at all propagated to repositories that are in the adjusted branch.
+
+* New files from other repositories are not created automatically in adjusted branch repos
+* Commited changes in files from other repositories are not reflected in in adjusted branch repos
+
+The manual states:
+>	To propigate  changes from  the adjusted branch  back to  the original
+>	branch, and to other repositories, as well as to merge in changes from
+>	other repositories, use git annex sync.
+
+I would expect that the assistant is just doing this, that I don't have to trigger the sync in the adjusted branch repo by myself.
+
+### What steps will reproduce the problem?
+
+Synchronizing several git annex repositories (three) with the assistant, with the second one being in the adjusted branch:
+
+* Create a new file in the first repository (normal v5, autocommit=true)
+* The file is being commited automatically and synchronized into the 3rd repository (normal v5).
+* But the file does not appear in the 2nd one, being in the adjusted branch
+
+Once you trigger
+    git annex sync
+in the 2nd repository, it seems the adjusted branch synchronizes with the master and the file appears.
+
+The same happens with changes in files.
+
+### What version of git-annex are you using? On what operating system?
+
+* git-annex version: 6.20160511-1~ubuntu14.04.1~ppa1
+* Linux 4.4.0-24-generic #43~14.04.1-Ubuntu x86_64
+* Linux Mint 17.3 Rosa
+
+### Please provide any additional information below.
+
+Assistant log from adjust branch repo.
+test7.txt is the new file created on other repo which didn't showed up immediately.
+
+[[!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
+(merging origin/git-annex into git-annex...)
+To /home/sven/Temporary/Annex1
+ + 9cc4eea...0e6c4ba git-annex -> synced/git-annex (forced update)
+(started...) 
+(merging synced/git-annex into git-annex...)
+(Merging into master...) Merge made by the 'recursive' strategy.
+ script.sh | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 script.sh
+(Merging into adjusted branch...) 
+Updating 449f26f..09950df
+Fast-forward
+ script.sh | 1 +
+ 1 file changed, 1 insertion(+)
+ create mode 100644 script.sh
+[2016-09-25 16:32:28.594537] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:32:28.631525] Pusher: Syncing with origin 
+To /home/sven/Temporary/Annex1
+   0e6c4ba..578f070  git-annex -> synced/git-annex
+   9754018..38c3683  master -> synced/master
+[2016-09-25 16:32:29.632224] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:32:30.661338] Pusher: Syncing with origin 
+Everything up-to-date
+(merging synced/git-annex into git-annex...)
+(merging synced/git-annex into git-annex...)
+(recording state in git...)
+git-annex: Daemon is already running.
+[2016-09-25 16:36:58.360139] Committer: Adding test7.txt
+add test7.txt ok
+[2016-09-25 16:36:58.476985] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:36:58.494964] Pusher: Syncing with origin 
+Everything up-to-date
+[2016-09-25 16:36:59.575623] Committer: Adding test7.txt
+add test7.txt ok
+[2016-09-25 16:36:59.578454] Committer: Committing changes to git
+(recording state in git...)
+[2016-09-25 16:37:00.506906] Pusher: Syncing with origin 
+Everything up-to-date
+# 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'm using git-annex a lot for synchronizing stuff between work, home, external backup discs, and now that I see the autocommit=false flag I'll surely start to use the assistant.
+And the new adjust branch is perfect for one of my use cases, but not like it behaves right now.
diff --git a/doc/bugs/Metadata_charset_not_uniform.mdwn b/doc/bugs/Metadata_charset_not_uniform.mdwn
new file mode 100644
index 000000000..19f6aa403
--- /dev/null
+++ b/doc/bugs/Metadata_charset_not_uniform.mdwn
@@ -0,0 +1,64 @@
+### Please describe the problem.
+
+Metadata are not stored in a consistent format. It seems more like git-annex chooses the "smallest" charset able to hold the data, i.e. US-ASCII, unless there are latin1 characters, and only UTF-8 if there are UTF-8 characters that are not in latin1
+
+### What steps will reproduce the problem?
+
+    % git init
+    Initialized empty Git repository in /home/madduck/.tmp/cdt.GlIevu/.git/
+    
+    % git annex init
+    init  ok
+    (recording state in git...)
+    
+    % date > a
+    
+    % git annex add a
+    add a ok
+    (recording state in git...)
+    
+    % git annex metadata -s one=$(echo US-ASCII | iconv -tus-ascii) a
+    metadata a 
+      lastchanged=2016-09-25@13-18-57
+      one=US-ASCII
+      one-lastchanged=2016-09-25@13-18-57
+    ok
+    (recording state in git...)
+    
+    % git annex metadata -s two=$(echo lätin1 | iconv -tlatin1) a
+    metadata a 
+      lastchanged=2016-09-25@13-19-37
+      one=US-ASCII
+      one-lastchanged=2016-09-25@13-18-57
+      two=lätin1
+      two-lastchanged=2016-09-25@13-19-37
+    ok
+    (recording state in git...)
+    
+    % git annex metadata -s three=$(echo unicode… | iconv -tutf8) a  
+    metadata a 
+      lastchanged=2016-09-25@13-19-41
+      one=US-ASCII
+      one-lastchanged=2016-09-25@13-18-57
+      three=unicode…
+      three-lastchanged=2016-09-25@13-19-41
+      two=lätin1
+      two-lastchanged=2016-09-25@13-19-37
+    ok
+    (recording state in git...)
+    
+    % git annex metadata -g three a | iconv -tutf8                 
+    unicode…
+    
+    % git annex metadata -g two a | iconv -tutf8 
+    liconv: illegal input sequence at position 1
+    
+    % git annex metadata -g one a | iconv -tutf8 
+    US-ASCII
+    
+    % git annex metadata -g two a | iconv -flatin1 -tutf8 
+    lätin1
+
+### What version of git-annex are you using? On what operating system?
+
+6.20160808-1
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment
new file mode 100644
index 000000000..d56e90c83
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_6_8e05f8769870b3f1aec77fca06f37284._comment
@@ -0,0 +1,7 @@
+[[!comment format=mdwn
+ username="PaulK"
+ subject="comment 6"
+ date="2016-09-24T04:16:51Z"
+ content="""
+Nope, no difference. Same \"ELF load command alignment not page-aligned\" errors as before.
+"""]]
diff --git a/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment
new file mode 100644
index 000000000..05fe1010a
--- /dev/null
+++ b/doc/bugs/git-annex_won__39__t_execute_on_WD_My_Cloud_NAS/comment_7_8da1f5fc6656e92dc2e3dabd9808f2d1._comment
@@ -0,0 +1,13 @@
+[[!comment format=mdwn
+ username="PaulK"
+ subject="comment 7"
+ date="2016-09-25T03:08:40Z"
+ content="""
+As an aside, just tried syncthing's arm verion, and I get a \"runtime: kernel page size (32768) is larger than runtime page size (4096)\" error. While their arm64 version also won't run.  
+
+Perhaps it's a similar issue with git-annex? Seems the page-size comes up in a number of contexts of people trying to get software running on the WD NAS.
+
+Is there any way to adjust  this page-size in the linker?
+
+Thanks
+"""]]
diff --git a/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn
new file mode 100644
index 000000000..bc89b1352
--- /dev/null
+++ b/doc/forum/DVD-R-based_archive_--_lack_of_backward_compatibility_seems_like_a_showstopper.mdwn
@@ -0,0 +1,15 @@
+I've been planning to use git-annex to manage a collection of DVD-Rs (of photos and the like), something along [these lines](https://git-annex.branchable.com/forum/How_do_I_backup_my_data_to_blue_ray_disks__63__/), and especially this paragraph therein:
+
+> If the [media is] not rewritable [which in my case it won't be; see below], I might try making the git-annex repo in a temporary directory on the hard disk, and then generating the ISO from that once I've filled it up. Should work fine, I might set "remote..annex-readonly" to true in git repos that had such a disk as a remote to let git-annex know to not try to write to it.
+
+But then there's this bug report: [read-only filesystem on remote prevents auto-upgrade from v3 to v5, and prevents using a remote](https://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/), and [Joey's comment]((http://git-annex.branchable.com/bugs/annex_get_fails_from_read-only_filesystem/#comment-67f204c3a4312bbda8ace305dbe0afbf):
+
+> From a code complication POV, it's useful for git-annex to only support one version of repository at a time.
+
+My concept depends on being able to restore files from my archive, N years and M git-annex versions later, using `git annex get` (after `git annex whereis` or the like to find out which volume to mount).  If I can't count on the *get* to work -- and indeed, can pretty much count on it *not* to, after the next format-version bump -- this whole scheme sounds like a nonstarter.
+
+> As far as backwards compatablity goes, I don't anticipate ever removing the upgrade code from git-annex.
+
+This is an archive; therefore it will use write-once media -- if it were rewritable, it would be clobberable should something (including `git-annex upgrade`!) go wrong.
+
+So, is there a way around this?  Or am I (and others) out of luck on using git-annex to manage long-term archival storage?
diff --git a/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment
new file mode 100644
index 000000000..5b1134be8
--- /dev/null
+++ b/doc/todo/interface_to_the___34__progress__34___of_annex_operations/comment_6_25f9cd3d341c60a059f462a34c89d1d6._comment
@@ -0,0 +1,8 @@
+[[!comment format=mdwn
+ username="https://me.yahoo.com/a/EbvxpTI_xP9Aod7Mg4cwGhgjrCrdM5s-#7c0f4"
+ subject="+may be "byte-target" field? ;)"
+ date="2016-09-24T02:43:21Z"
+ content="""
+THANK YOU for implementing this feature -- we will make use of it soon.
+But so we don't do reverse estimation from \"byte-progress\" and \"percent-progress\", and didn't have to get it from a key (which might not have it e.g. in case of URL relaxed backend) -- could you just include in each record the \"byte-target\" (if known) or something like that? ;)  thanks in advance!
+"""]]
diff --git a/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment b/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment
new file mode 100644
index 000000000..bf6887ec5
--- /dev/null
+++ b/doc/todo/transitive_transfers/comment_4_cb92e81c1ea00ca72f9a5ee729d627f4._comment
@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="erics"
+ subject="comment 4"
+ date="2016-09-25T00:33:56Z"
+ content="""
+> And there is a complication with running [`git annex copy --from --to`] at the same time as eg `git annex get` of the same file. It would be surprising for get to succeed (because copy has already temporarily downloaded the file) and then have the file later get dropped.
+
+A solution to this subproblem would transparently fall out of a facility for [logically dropping files](http://git-annex.branchable.com/todo/wishlist__58_____96__git_annex_drop_--relaxed__96__/#comment-9672d46a18a381971dd818cde6efbc33), which was briefly talked about a long time ago.  Just mark the file as *logically dropped*.  If the user `git annex get`s it while the copy-out is in progress, its status will change to \"present\", so *copy* will know not to physically delete it.
+
+(Of course there are race conditions involved, but I presume/hope that they're no worse than git-annex already has to deal with.)
+"""]]