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

doc: perl -p -i -e s/certianly/certainly/

Browse source
This commit is contained in:
Richard Hartmann 2013-11-25 21:40:19 +01:00
parent 95221c7252
commit be43bb8f70
48 changed files with 48 additions and 48 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/design/assistant/blog/day_114__xmpp/comment_2_d14375dfb5791615802dab3c5438f8e2._comment
View file

@ -4,5 +4,5 @@
subject="comment 2"
date="2012-11-09T21:55:42Z"
content="""
It does try to mark itself as extended away, but yes, I think this is a potential concern. If you find the assistant interacts badly with your other clients, you can certianly give it its own XMPP account.
It does try to mark itself as extended away, but yes, I think this is a potential concern. If you find the assistant interacts badly with your other clients, you can certainly give it its own XMPP account.
"""]]

2
doc/design/assistant/blog/day_140__release_monday.mdwn
View file

@ -19,7 +19,7 @@ Still working on getting the standalone builds for this release done,
should be done by the end of today.
Also found a real stinker of a bug in `dirContentsRecursive`, which was
just completely broken, apparently since day 1. Fixing that has certianly
just completely broken, apparently since day 1. Fixing that has certainly
fixed buggy behavior of `git annex import`. It seems that the other
user of it, the transfer log code, luckily avoided the deep directory
trees that triggered the bug.

2
doc/design/assistant/blog/day_76__pairing/comment_2_8e1b2233579bc26bfd758bbf6b3bdc07._comment
View file

@ -6,5 +6,5 @@
content="""
The [[bugs]] page is the place to put bug reports like this so I won't forget them.
This should certianly not be happening. There are actually two git-annex processes running in the situation you describe; I'd be most curious to know whether the `git annex transfer` process was the one that blew up, or if the `git annex assistant` blew up. Also, it's not clear to me if you enabled the chunksize parameter when setting up the special remote, which could well be a significant detail.
This should certainly not be happening. There are actually two git-annex processes running in the situation you describe; I'd be most curious to know whether the `git annex transfer` process was the one that blew up, or if the `git annex assistant` blew up. Also, it's not clear to me if you enabled the chunksize parameter when setting up the special remote, which could well be a significant detail.
"""]]

2
doc/design/assistant/blog/day_83__3-way.mdwn
View file

@ -68,6 +68,6 @@ still possible with other network topologies (ie, if D is connected to both
B and C, there would be an upload loop 'B -> C -> D -> B`). So unless I can
find a better event to hook into, this idea is doomed.
I do have another idea to fix the same problem. C could certianly remember
I do have another idea to fix the same problem. C could certainly remember
that it saw a file and didn't know where to get the content from, and then
when it receives a git push of a git-annex branch, try again.