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

doc/forum/pure_git-annex_only_workflow/comment_14_b63568b327215ef8f646a39d760fdfc0._comment

@@ -0,0 +1,32 @@
+[[!comment format=mdwn
+ username="http://www.joachim-breitner.de/"
+ nickname="nomeata"
+ subject="comment 14"
+ date="2012-01-02T14:02:04Z"
+ content="""
+Sorry for not replying earlier, but my non-mailinglist-communications-workflows are suboptimal :-)
+
+> Then in each repo, I found I had to pull from each of its remotes, to get the tracking branches that defaultSyncRemotes looks for to know those remotes are syncable.  This was the surprising thing for me, I had expected sync to somehow work out which remotes were syncable without my explicit pull. And it was not very obvious that sync was not doing its thing before I did that, since it still does a lot of \"stuff\".
+
+Right. But \"git fetch\" ought to be enough.
+
+Personally, I’d just pull and push everywhere, but you pointed out that it ought to be manageable. The existence of the synced/master branch is the flag that indicates this, so you need to propagate this once. Note that if the branch were already created by \"git annex init\", then this would not be a problem.
+
+It is not required to use \"git fetch\" once, you can also call \"git annex sync <remote>\" once with the remote explicitly mentioned; this would involve a fetch.
+
+> While this would lose the ability to control which remotes are synced, I think that being able to git annex sync origin and only sync from/to origin is sufficient, for the centralized use case.
+
+I’d leave this decision to you. But I see that you took the decision already, as your code now creates the synced/master branch when it does not exist (e290f4a8).
+
+> Why did you make branch strict?
+
+Because it did not work otherwise :-). It uses pipeRead, which is lazy, and for some reason git and/or your utility functions did not like that the output of the command was not consumed before the next git command was called. I did not investigate further. For better code, I’d suggest to add a function like pipeRead that completely reads the git output before returning, thus avoiding any issues with lazyIO.
+
+> mergeRemote merges from refs/remotes/foo/synced/master. But that will only be up-to-date if git annex sync has recently been run there. Is there any reason it couldn't merge from refs/remotes/foo/master?
+
+Hmm, good question. It is probably save to merge from both, and push only to synced/master. But which one first? synced/master can be ahead if the repo was synced to from somewhere else, master can be ahead if there are local changes. Maybe git merge should be called on all remote heads simultaniously, thus generating only one commit for the merge. I don’t know how well that works in practice.
+
+Thanks for including my code,
+Joachim
+
+"""]]

doc/forum/pure_git-annex_only_workflow/comment_15_cb7c856d8141b2de3cc95874753f1ee5._comment

@@ -0,0 +1,12 @@
+[[!comment format=mdwn
+ username="http://joey.kitenet.net/"
+ nickname="joey"
+ subject="comment 15"
+ date="2012-01-02T16:01:49Z"
+ content="""
+With a lazy branch, I get \"git-annex: no branch is checked out\". Weird.. my best guess is that it's because this is running at the seek stage, which is unusual, and the value is not used until a later stage and so perhaps the git command gets reaped by some cleanup code before its output is read.
+
+(pipeRead is lazy because often it's used to read large quantities of data from git that are processed progressively.)
+
+I did make it merge both branches, separately. It would be possible to do one single merge, but it's probably harder for the user to recover if there are conflicts in an octopus merge. The order of the merges does not seem to me to matter much, barring conflicts it will work either way. Dealing with conflicts during sync is probably a weakness of all this; after the first conflict the rest of the sync will continue failing.
+"""]]

doc/tips/using_gitolite_with_git-annex/comment_8_8249772c142117f88e37975d058aa936._comment

@@ -0,0 +1,29 @@
+[[!comment format=mdwn
+ username="bremner"
+ ip="156.34.79.193"
+ subject="afaict git annex normalizes urls on the client side."
+ date="2011-12-31T22:29:38Z"
+ content="""
+After some debugging printing, here is my current understanding.
+
+- urls of the form git@host:~repo or ssh://git@host
+
+  - git sends commands like  \"git-receive-pack '~/repo'
+  - gitolite converts these to $REPO_BASE/~/repo which fails.  ~/repo would also fail fwiw.
+  - git-annex sends seems /~/repo, which works
+
+- urls of the form git@host:/repo or ssh://git@host/repo
+
+  - git sends \"git-receive-pack '/db/cs3383'\"
+  - gitolite converts this to $REPO_BASE/repo which works
+  - git annex sends \"git-annex-shell 'inannex' '/repo' ...\" which works, but only with the patch above.
+
+- urls of the form git@host:repo
+
+  - git sends \"git-receive-pack 'repo'
+  - gitolite converts this to $REPO_BASE/repo, which works
+  - git-annex sends \"git-annex-shell 'inannex' '/~/db/cs3383'...\", which also works for git-annex-shell.
+
+So the weird case is the last one where git and git-annex are sending different things over the wire.
+I don't know if you have other motivations for doing the url normalization on the client side, but it isn't needed for gitolite, and in some sense complicates things a little.  On the other hand, now that I see what is going on, it isn't a big deal to just strip the leading /~ off in the adc. It does lead to the odd situation of some URLs working for git-annex but not git.
+"""]]