mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

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

Browse source
This commit is contained in:
Joey Hess 2013-06-25 15:50:24 -04:00
commit 725ebbf62d
17 changed files with 171 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

14
doc/bugs/Deasn__39__t_clean_up_ssh_keys_after_removing_remote_repo/comment_1_88fbf70eae48484988dbb433a437c717._comment Normal file
View file

@ -0,0 +1,14 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.193"
subject="comment 1"
date="2013-06-25T18:20:05Z"
content="""
It's true that deleting a ssh repository in the webapp does not delete any ssh keys that the webapp configured to access that repository. I'm a bit reluctant to try to clean it up entirely automatically, because the ssh configuration might have been manually altered, or might be used by another local repository. Particularly, if another local repo is set up to use the same ssh remote, the webapp will reuse the ssh key.
> Create, delete and create again a new repo on remote ssh server with password auth.
I tried doing this, and did not encounter any problem. Since the new repo had a different path on the ssh server, I simply ended up with two ssh keys configured in `~/.ssh/config` for two different repositories. The presence or absence of the first key did not affect the second key.
I think you need to go into more detail about exactly what you did, or show the files in .ssh that were set up, so I can see what the actual problem is.
"""]]

8
doc/bugs/Hanging_on_install_on_Mountain_lion/comment_5_2a336fe7b8aed07cbdaa868bd34078f9._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.193"
subject="comment 5"
date="2013-06-25T17:14:02Z"
content="""
To get this fixed, someone is going to need to do some investigation of what is happening. I do not have resources to debug OSX problems that cannot be reproduced using the command line.
"""]]

10
doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_1_8229df64a872bee7590f75eb78f78c4a._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.193"
subject="comment 1"
date="2013-06-25T18:08:55Z"
content="""
As far as I know, there have been no changes to the local pairing protocol that would cause a problem like this. 3.20121112 is a few months after local pairing was first developed.
Have you tried upgrading and re-pairing?
"""]]

12
doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_2_f37be896396915b1c85cff8811dceb4a._comment Normal file
View file

@ -0,0 +1,12 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawm01ida6POv7vqyUYtOlymEbJTbrImAIzM"
nickname="Reinis"
subject="comment 2"
date="2013-06-25T18:50:00Z"
content="""
I have not tried to upgrade, but I fixed it using annex describe followed by assistant restart as hinted in /usr/share/doc/git-annex/html/bugs/uuid.log_trust.log_and_remote.log_merge_wackiness.html.
From that document I understood that at worst it should use one of the two uuids (from Ubuntu or Gentoo repo), but it should not leave it without uuid and hence this report.
I have tried it a couple of times and it is perfectly reproducible.
"""]]

10
doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_3_df7fc1078059538a76f384a40541e91f._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.193"
subject="comment 3"
date="2013-06-25T19:13:06Z"
content="""
An old bug report that was fixed in 2011 seems very unlikely to have anything to do with your local pairing problem.
Why don't you try upgrading?
"""]]

8
doc/bugs/Missing_repo_uuid_after_local_pairing_with_older_annex/comment_4_70c444c61f41df2f59294c10f94f0c09._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawm01ida6POv7vqyUYtOlymEbJTbrImAIzM"
nickname="Reinis"
subject="comment 4"
date="2013-06-25T19:34:12Z"
content="""
I was expecting the version in distribution which came out two months ago to be somewhat recent, probably unfounded expectation for non-rolling release distribution. I'll add PPA and try using that one.
"""]]

8
doc/bugs/Problems_with_syncing_gnucash/comment_1_ca195af3ba4a286eb5ab687634192fa4._comment Normal file
View file

@ -0,0 +1,8 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.193"
subject="comment 1"
date="2013-06-25T17:30:05Z"
content="""
First of all, are you sure that git-annex is even the right tool for this job? gnucash files tend to be pretty small, and are easy to check into git directly. What happens if two machines make conflicting edits, and the git-annex assistant automatically resolves the merge conflict by moving files around and making .variant copies of gnucash log files?
"""]]

20
doc/bugs/Problems_with_syncing_gnucash/comment_2_754fb430381ad88e6248ecb902b32118._comment Normal file
View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.193"
subject="comment 2"
date="2013-06-25T17:49:08Z"
content="""
I was able to reproduce this with gnucash, and came up with a small test case:
[[!format perl \"\"\"
my $foo=\"foo\";
open(OUT, \">$foo.new\");
link(\"$foo.new\", \"$foo\");
unlink(\"$foo.new\");
close OUT;
\"\"\"]]
This defeats the watcher, which sees the file be opened for write, and then deleted before it's closed. To fix this it would need to correlate the hard link with the original file, to know that when the original file is closed, the hard link can now be safely added to the annex.
The daily sanity checker will find and eventually add these files, or the assistant will see them the next time it's started.
"""]]