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

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

Browse source
This commit is contained in:
Joey Hess 2012-11-11 17:44:09 -04:00
commit 8644d72ffb
6 changed files with 62 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

22
doc/bare_repositories/comment_1_148e1da70d37d311634a0309a4ff8dcd._comment Normal file
View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="https://www.google.com/accounts/o8/id?id=AItOawmraN_ldJplGunVGmnjjLN6jL9s9TrVMGE"
nickname="Ævar Arnfjörð"
subject="How to convert bare repositories to non-bare"
date="2012-11-11T20:14:44Z"
content="""
I made a repository bare and later wanted to convert it, this would have worked with just plain git:
cd bare-repo.git
mkdir .git
mv .??* * .git/
git config --unset core.bare
git reset --hard
But because git-annex uses different hashing directories under bare repositories all the files in the repo will point to files you don't have. Here's how you can fix that up assuming you're using a backend that assigns unique hashes based on file content (e.g. the SHA256 backend):
mv .git/annex/objects from-bare-repo
git annex add from-bare-repo
git rm -f from-bare-repo
"""]]

10
doc/bugs/acl_not_honoured_in_rsync_remote/comment_2_ffb9424e966ee10a4fe2d446b3042cb2._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://christian.amsuess.com/chrysn"
nickname="chrysn"
subject="further tracking"
date="2012-11-11T01:15:41Z"
content="""
the behavior is rooted in rsync, which behaves similar to `mkdir -p`. it can probably be worked around by configuring the rsync option `--chmod=775`, but that would add executability to files.
i've opened a bug in rsync's bug tracker at <https://bugzilla.samba.org/show_bug.cgi?id=9377>, let's see what the developer says.
"""]]

9
doc/bugs/network___62____61___2.4.0.1_is_not_in_Haskell_Platform_2012.4.0.0.mdwn Normal file
View file

@ -0,0 +1,9 @@
git-annex requires version 2.4.0.1 or later of the 'network' library. Unfortunately,
the current version of the Haskell Platform mandates version 2.3.1.0 of that library.
This means that git-annex cannot be compiled on the Haskell Platform 2012.4.0.0 (which
is going to remain the HP version of choice until May next year or so).
Do you think it's possible to support *both* versions of the network library, maybe?
That would increase the portability of git-annex quite a bit.
Thank you for your consideration.

10
doc/design/assistant/xmpp/comment_1_f20650f93d7f0ca39b9ba3ce0380193f._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://meep.pl/"
ip="193.23.174.18"
subject="xmlns"
date="2012-11-11T09:00:01Z"
content="""
A minor point, but is saving a couple of bytes per message worth using a [deprecated feature](http://www.w3.org/TR/REC-xml-names/#iri-use) of the namespaces specification? This is not technically *breaking* the current specification, since \"git-annex\" is of course still a (relative) URI reference; and anyway chances of problems are, I guess, slim. But is it the lesser of two bugs?
The shortest moderately sane absolute URI containing \"git-annex\" would probably be \"data:,git-annex\".
"""]]

10
doc/forum/Unlock_files_when_assistant_is_running__63__/comment_1_3f4aadf0c856c81e15c6f5ae7f1992b4._comment Normal file
View file

@ -0,0 +1,10 @@
[[!comment format=mdwn
username="http://joeyh.name/"
ip="4.152.108.27"
subject="comment 1"
date="2012-11-11T16:06:42Z"
content="""
I suspect you have an old build of the assistant. Version 3.20121009 was supposed to fix this.
I re-tested with current git head today, and found I was able to unlock a file, repeatedly edit it in place without the assistant re-adding it, and then run \"git annex add\" and the assistant auto-committed the changed file. Better behavior than I was expecting in fact -- the ability to repeatedly edit is a pleasant surprise.
"""]]

2
doc/sync.mdwn
View file

@ -22,7 +22,7 @@ fetches from each remote, and merges in any changes that have been made
to the remotes too. Finally, it updates `synced/master` to reflect the new to the remotes too. Finally, it updates `synced/master` to reflect the new
state of `master`, and pushes it out to each of the remotes. state of `master`, and pushes it out to each of the remotes.
This way, changes propigate around between repositories as `git annex sync` This way, changes propagate around between repositories as `git annex sync`
is run on each of them. Every repository does not need to be able to talk is run on each of them. Every repository does not need to be able to talk
to every other repository; as long as the graph of repositories is to every other repository; as long as the graph of repositories is
connected, and `git annex sync` is run from time to time on each, a given connected, and `git annex sync` is run from time to time on each, a given