diff options
author | Joey Hess <joey@kitenet.net> | 2014-07-15 17:44:56 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2014-07-15 17:44:56 -0400 |
commit | 697c5c187aef7deb6bd08e44c5ffcdf123da387b (patch) | |
tree | ccb9545ae3f575da14dea0dd429f1719a05b4132 /doc/devblog | |
parent | 2bc4f99805f77fc63efbbee6eb89cad0cb0a3de9 (diff) |
devblog
Diffstat (limited to 'doc/devblog')
-rw-r--r-- | doc/devblog/day_198__branching_out.mdwn | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/doc/devblog/day_198__branching_out.mdwn b/doc/devblog/day_198__branching_out.mdwn new file mode 100644 index 000000000..cdb3a6d1b --- /dev/null +++ b/doc/devblog/day_198__branching_out.mdwn @@ -0,0 +1,23 @@ +I have mostly been thinking about gcrypt today. +[This issue](https://github.com/blake2-ppc/git-remote-gcrypt/issues/9) +needs to be dealt with. The question is, does it really make sense to +try to hide the people a git repository is encrypted for? I have +[posted some thoughts](http://git-annex.branchable.com/bugs/using_gpg_encryption_with_multiple_keys_fails/?updated#comment-0c4f679d972c63b0b25b6aa5e851af62) +and am coming to the viewpoint that obscuring the identities of users +of a repository is not a problem git-annex should try to solve itself, +although it also shouldn't get in the way of someone who is able and +wants to do that (by using tor, etc). + +Finally, I decided to go ahead and add a gcrypt.publish-participants +setting to git-remote-gcrypt, and make git-annex set that by default when +setting up a gcrypt repository. + +Some promising news from the ghc build on arm. I got a working ghc, and +even ghci works. Which would make the template haskell in the webapp etc +avaialble on arm without the current horrible hacks. Have not managed to +build the debian ghc package successfully yet though. + +Also, fixed a bug that made `git annex sync` not pull/push with a local +repository that had not yet been initialized for use with git-annex. + +Today's work was sponsored by Stanley Yamane. |