Merge branch 'master' of ssh://git-annex.branchable.com
This commit is contained in:
Joey Hess
commit
8155b541e0
15 changed files with 256 additions and 0 deletions
|
|
@ -0,0 +1,12 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawl99Gxq3NPNvwZHp3PDufaknQH4rZb_KKY"
|
||||
nickname="Florian"
|
||||
subject="comment 2"
|
||||
date="2013-04-12T15:21:11Z"
|
||||
content="""
|
||||
I found a different workaround. I added the remote repo via the \"remote server\" option. After that I shut down the local assistant and deleted all the new bare repository stuff on the remote machine. After restarting the local assistant syncing worked as expected and no new bare repository was initialized.
|
||||
|
||||
On an other machine I was able to transform the bare repository into a non-bare one and check out the files. After that syncing also still worked.
|
||||
|
||||
The remote git-annex-shell is working well. I already described this in an other bug report, where I always ended up in it while trying to log into the machine manually.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawl99Gxq3NPNvwZHp3PDufaknQH4rZb_KKY"
|
||||
nickname="Florian"
|
||||
subject="comment 4"
|
||||
date="2013-04-12T15:01:16Z"
|
||||
content="""
|
||||
I think I found a part of the problem. I still don't know why there was this strange key setup in the beginning. Maybe i did this manually and forgot about it instantly...
|
||||
|
||||
However, today I again had the problem with ending up in git-annex-shell on the commandline. To debug this I called ssh -vvv ... and found out that ssh somehow found the private key in ~/.ssh/key.git-annex-servername-username and ofcourse tried to use it.
|
||||
Moving the key to a subdirectory in ~/.ssh/ and fixing the path in ~/.ssh/config solved my problem again.
|
||||
"""]]
|
||||
52
doc/bugs/Weird_behaviour_of_direct_and_indirect_annexes.mdwn
Normal file
52
doc/bugs/Weird_behaviour_of_direct_and_indirect_annexes.mdwn
Normal file
|
|
@ -0,0 +1,52 @@
|
|||
## What steps will reproduce the problem?
|
||||
|
||||
~$ git annex webapp
|
||||
|
||||
|
||||
* Add Another Local Repository (~/Direct) "Direct", keep separate (from existing repo) no repo type
|
||||
* Add Repository, ~/Indirect "Indirect", combine (with Direct) , repo type client
|
||||
* Syncing enabled on both
|
||||
|
||||
Then
|
||||
|
||||
~/Indirect$ git annex indirect
|
||||
commit ok
|
||||
indirect ok
|
||||
ok
|
||||
~/Indirect$ touch ../Direct/Test.File
|
||||
|
||||
|
||||
## What is the expected output? What do you see instead?
|
||||
|
||||
That ~/Indirect/Test.File be a symlink into .git/annex/objects/.......
|
||||
|
||||
Instead, it is not a symlink. However, doing
|
||||
|
||||
~/Indirect$ git annex direct
|
||||
~/Indirect$ git annex indirect
|
||||
|
||||
results in what I would expect (until the content of Direct/Test.File is changed, when it ceases to be a symlink in ~/Indirect once more)
|
||||
|
||||
|
||||
|
||||
## What version of git-annex are you using? On what operating system?
|
||||
git-annex version: 4.20130405
|
||||
|
||||
Ubuntu 12.10
|
||||
|
||||
|
||||
## Please provide any additional information below.
|
||||
|
||||
Reading [[direct_mode]], I thought that I could have two repos on my computer, one direct, and one indirect, and if running the assistant, that I could gain the security of retaining old versions, as well as the convenience of direct mode. (I think I understand that correctly; if a direct-mode file only exists in one repository, and is edited, the old version is lost, but if it is in multiple repos, then the old versions will be retained).
|
||||
|
||||
It seems to me that if I do
|
||||
|
||||
~/Direct$ echo Content > Test.File
|
||||
~/Direct$ echo More Content > Test.File
|
||||
~/Direct$ echo Even More Content > Test.File
|
||||
|
||||
that all three copies are stored in ~/Indirect, so the functionality I'm after seems to work. However, ~/Indirect/Test.File ends up not being a symlink, which I think is odd/unexpected.
|
||||
|
||||
|
||||
**Edit: Doing a git annex sync in ~/Indirect results in the continuing behaviour to be correct, so there's some issue telling Direct that Indirect is no longer in direct-mode?**
|
||||
This appears to fix it, but I guess shouldn't be necessary.
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawnSenxKyE_2Z6Wb-EBMO8FciyRywjx1ZiQ"
|
||||
nickname="Walter"
|
||||
subject="Commands to accomplish same"
|
||||
date="2013-04-13T04:43:41Z"
|
||||
content="""
|
||||
I feel that the following commands should do essentially the same (ie they do what I intend to do).
|
||||
More, they even display the correct (expected) behaviour, it seems the strangeness is introduced by the webapp (which, by the way, is really cool).
|
||||
|
||||
cd ~
|
||||
mkdir Direct Indirect
|
||||
git init Direct/
|
||||
git init Indirect/
|
||||
cd Direct/
|
||||
git annex init Direct
|
||||
git annex direct
|
||||
cd ../Indirect
|
||||
git annex init Indirect
|
||||
git annex indirect
|
||||
touch Indirect
|
||||
git annex add Indirect
|
||||
git commit -m 'Initial commit'
|
||||
git remote add Direct ..//Direct/
|
||||
git annex assistant
|
||||
cd ../Direct/
|
||||
touch Direct
|
||||
git annex add Direct
|
||||
git commit -m 'Initial commit'
|
||||
git remote add Indirect ../Indirect
|
||||
git annex assistant
|
||||
touch Test
|
||||
echo Test > Test
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
[[!comment format=mdwn
|
||||
username="Xyem"
|
||||
ip="87.194.19.134"
|
||||
subject="comment 2"
|
||||
date="2013-04-13T20:50:16Z"
|
||||
content="""
|
||||
Ah I see. Bit of a misunderstanding on my end about what the groups did, by the looks of it. I was under the impression they controlled how files moved around, if at all (as described in the webapp), and the preferred-content was just fine-tuning controls.
|
||||
|
||||
I just went to set this back up to see if setting it to \"standard\" in vicfg works how I want it to and now I've hit a different problem. The webapp/assistant isn't populating the git commit messages on it's own, it is launching $EDITOR (vi if unset on my system) in the background to prompt me for it (where I can't see it).
|
||||
|
||||
├─xterm
|
||||
│ └─bash
|
||||
│ └─git annex webapp
|
||||
│ └─git-annex webapp
|
||||
│ ├─git --git-dir=/home/xyem/tmp/annex/.git --work-tree=/home/xyem/tmp/annex cat-file --batch
|
||||
│ ├─git --git-dir=/home/xyem/tmp/annex/.git --work-tree=/home/xyem/tmp/annex cat-file --batch
|
||||
│ ├─git --git-dir=/home/xyem/tmp/annex/.git --work-tree=/home/xyem/tmp/annex check-attr -z --stdin annex.backend annex.numcopies --
|
||||
│ ├─git --git-dir=/home/xyem/tmp/annex/.git --work-tree=/home/xyem/tmp/annex commit --allow-empty-message -m --quiet --no-verify
|
||||
│ │ └─nano .git/COMMIT_EDITMSG
|
||||
│ └─6*[{git-annex}]
|
||||
|
||||
If I do the steps manually, it seems to work fine:
|
||||
|
||||
$ echo \"testfile\" > testfile.txt
|
||||
$ git annex add testfile.txt
|
||||
|
||||
add testfile.txt (checksum...) ok
|
||||
(Recording state in git...)
|
||||
|
||||
$ git --git-dir=/home/xyem/tmp/annex/.git --work-tree=/home/xyem/tmp/annex commit --allow-empty-message -m --quiet --no-verify
|
||||
|
||||
[master 636605f] --quiet
|
||||
1 file changed, 1 insertion(+)
|
||||
create mode 120000 testfile.txt
|
||||
|
||||
This, to me, implies it is a bug with the assistant/webapp but I don't know how to isolate it any more than that (--debug doesn't output anything else). Should I report this as another bug?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="Xyem"
|
||||
ip="87.194.19.134"
|
||||
subject="comment 3"
|
||||
date="2013-04-13T22:02:09Z"
|
||||
content="""
|
||||
Just noticed (while trying to commit in another annex) that the command I used above in the \"manual\" one commits with the message \"--quiet\". I guess pstree doesn't show all arguments!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawksoT5jmbiZ9UghROilchqy3kNJ1XGqCAo"
|
||||
nickname="Rob"
|
||||
subject="Drag and Drop"
|
||||
date="2013-04-12T03:37:53Z"
|
||||
content="""
|
||||
Is this along the lines of what you are looking for? http://www.dropzonejs.com/
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="marvin"
|
||||
ip="91.152.75.65"
|
||||
subject="Happy Birthday"
|
||||
date="2013-04-12T17:52:43Z"
|
||||
content="""
|
||||
Great work!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="robconnolly"
|
||||
ip="118.90.78.117"
|
||||
subject="comment 3"
|
||||
date="2013-04-13T03:12:14Z"
|
||||
content="""
|
||||
Thanks for fixing the addurl bug and Happy Birthday!
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://pradermecker.myopenid.com/"
|
||||
ip="81.244.179.73"
|
||||
subject="Local rsync ssh remote (I am confused)"
|
||||
date="2013-04-13T17:54:06Z"
|
||||
content="""
|
||||
If I understand this right, it is not possible to use git-annex as a simple wrapper around rsync.
|
||||
|
||||
My use case is this: I have a music folder on a plug computer running debian squeeze. The plug computer acts as a streaming music server. My wish is to create a local ssh remote to have my laptop git-annex music repo in sync with the plug computer. So ideally I don't want to install git-annex on the plug computer (but git is there so a git bare repo can be used).
|
||||
|
||||
According to the UI, if I use \"Pairing with a local computer\", both computers needs to have git-annex installed. If I try \"Remote server\" either I need both machines git-annex aware or I need the content of the plug computer to be encrypted (which is obviously not what I want in this case).
|
||||
|
||||
Is the use case supported by the UI ? Should I try with the CLI ?
|
||||
|
||||
Thanks for your help
|
||||
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawmU_2tE75oyG0h2ZPN4lcroIKEMC8G-otE"
|
||||
nickname="Michael"
|
||||
subject="comment 6"
|
||||
date="2013-04-12T06:31:17Z"
|
||||
content="""
|
||||
@joey But a *manual* node will still be the middleman between say a remote host and a local usb connected to the node?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://edheil.wordpress.com/"
|
||||
ip="173.162.44.162"
|
||||
subject="comment 7"
|
||||
date="2013-04-12T13:30:24Z"
|
||||
content="""
|
||||
As I understand it, nothing will \"be the middleman\" in the sense of, if annex A has remotes B and C, grabbing content from B in order to give it to C without regards for whether or not A wants it. Annex A doesn't think in terms of moving content from one remote to another remote, only in terms of pulling and pushing to remotes individually.
|
||||
|
||||
I get the \"move content from remote B to C\" effect by setting numcopies=2 and making both remotes \"backup.\" If content is only on remote B, it will migrate to A in order to fulfill numcopies. Then it will migrate to C because of C's preferred content settings.
|
||||
|
||||
(Respecting minimum numcopies is higher priority than respecting preferred content settings, so even if A wouldn't normally \"want\" the content, it will receive it if it needs to in order to fulfill numcopies.)
|
||||
|
||||
I've got A set to \"client\" so content in archive directories disappears once the content is on B and C (because numcopies is fulfilled, and so A's preferred content can take effect.)
|
||||
|
||||
If you had A set to \"manual,\" then it wouldn't automatically drop content once it moved from B to A to C, though. Because it would only drop things manually.
|
||||
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
[[!comment format=mdwn
|
||||
username="http://joeyh.name/"
|
||||
nickname="joey"
|
||||
subject="comment 3"
|
||||
date="2013-04-12T22:25:12Z"
|
||||
content="""
|
||||
John has gotten back to me with some analysis. The authentication failure is when SCRAM-SHA-1 is used. Ejabberd is rejecting the client's authentication request with a reason of \"bad-protocol\". It's not clear if ejabberd is broken or if gsasl is generating a bad SCRAM-SHA-1 authentication. We're inclined toward the latter, and will be forwarding this on to ejabberd.
|
||||
|
||||
The only way to turn off this authentication in ejabberd is to configure it to store passwords in plain text, or downgrade to a version older than 2.1.9, which first added it. Note that debian stable contains 2.1.5.3, so is not currently affected, for example.
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,8 @@
|
|||
[[!comment format=mdwn
|
||||
username="andy"
|
||||
ip="99.48.75.171"
|
||||
subject="Re: Webhook special remote"
|
||||
date="2013-04-12T08:54:47Z"
|
||||
content="""
|
||||
@Alex: You might see if the newly-added [[todo/wishlist: allow configuration of downloader for addurl]] could be made to do what you need... I've not played around with it yet, but perhaps you could set the downloader to be something that can sort out the various URLs and send them to the correct downloading tool?
|
||||
"""]]
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
[[!comment format=mdwn
|
||||
username="https://www.google.com/accounts/o8/id?id=AItOawnx8kHW66N3BqmkVpgtXDlYMvr8TJ5VvfY"
|
||||
nickname="Yaroslav"
|
||||
subject="how to drop one of the urls?"
|
||||
date="2013-04-12T14:53:29Z"
|
||||
content="""
|
||||
is there a way to remove one of the urls? e.g. if I have
|
||||
|
||||
$> git annex whereis fail2ban_logo.png
|
||||
whereis fail2ban_logo.png (1 copy)
|
||||
00000000-0000-0000-0000-000000000001 -- web
|
||||
|
||||
web: http://www.fail2ban.org/fail2ban_logo.png
|
||||
web: http://www.onerussian.com/tmp/statsmodes.png
|
||||
ok
|
||||
|
||||
and would like to remove the fail2ban.org one... ?
|
||||
"""]]
|
||||
Loading…
Add table
Add a link
Reference in a new issue