(why?)ĭeploy the following crappy plugin to make commits work again and make sure the right files are added in git-annex: Next, change into the /Dropbox/annex folder and make it aware of the /myrepo folder with the command: git remote add UbuntuServer /myrepo. (!) This needs to be done on ANY clone of the repository, which is annoying, but it's important because we don't want to see git-annex stuff in the bare repo.
Make the bare repository (the remote of $srcdir) ignored by git-annex: cd $srcdir Version: v0.0.10 Latest Latest This package is not in the latest version of its module.
So as the discussion shows, it seems it's perfectly possible to actually do this! There's this gallery site which uses the album plugin and git-annex to manage its files.Ĭonfigure direct mode because ikiwiki ignores symlinks for security reasons: cd $srcdirĬonfigure files to be considered by git-annex (those will be not committed into git directly): git config annex.largefiles 'largerthan=100kb and not (include=*.mdwn or include=*.txt)' I'd like to make symlinks possible without compromising security,īut it'll be necessary to be quite careful. One technical problem with this is that ikiwiki doesn't allow symlinksįor security, but git-annex relies on symlinks (unless you're inĭirect mode, but I'm not sure that's really desirable here). Ideally, a big file pushed would be hardlinked between the two repos, but it seems git-annex doesn't support that yet. The only problem I see with this is those files would end up in the bare repository and not necessarily show up in the web rendering. This would assume, of course, that there's another repo somewhere that ikiwiki has access to, which works for HTTP-style remotes, but could be more problematic for SSH remotes that require a key.Īnother solution would be to make ikiwiki a remote itself and allow users to push big files to it. I am not sure how this would work, but from my POV, it should do a git annex get when new commits are pushed to its bare repo. However, I have not tested this any further to ensure that git annex ignores the url and uses only the annex-rsyncurl entry when operating with annexed files.A dear wishlist which would resolve this question: ikiwiki should support git-annex repositories. git/config with both a url= (for the normal git operations) and a annex-rsyncurl=. Git remote add server-c annex initremote server-c type=rsync rsyncurl=:/rsync/user encryption=noneįor me this results in a single remote in. The following commands appear to create a sensible. It may be possible to point a single remote to both locations, however I'm not sure if this is actually supported. In particular you just have to remember to use the special remote (server-c-rsync) when using the -to= or -from= arguments of get, copy, and move.
The only downside is that you have 2 different remote names that really point to the same server. This should get you the basic functionality that you're looking for. You should be able to set this up with something along the lines of: git remote add server-c annex initremote server-c-rsync type=rsync rsyncurl=:/home/user/annex-rsync encryption=none Url = +refs/heads/*:refs/remotes/server-c/*Īnnex-rsyncurl = :/home/user/annex-rsync The second remote is an annex special remote. The first remote (server-c) is a regular git remote for synchronizing your history and anything that is checked directly into the git repo. Synchronize a local repository with a remote. Basically, you'll end up with 2 separate remotes, both pointing to different locations on server-c. git-annex linux command man page: Manage files with git, without checking their contents in. It looks like you've already read up on all of the tools you'll need. These could also be decoupled and stored on any number of different servers. man git-annex-testremote (1): This tests a remote by generating some random objects and sending them to the remote, then redownloading them, removing them from the remote, etc. With git and rsync access to the same server you can use that server to store both the history (via git access) and the annex key-value store (via rsync access).
0 kommentar(er)
