git-annex/doc/devblog/day_23__GNU_day.mdwn
Joey Hess e213ef310f git-annex (5.20140717) unstable; urgency=high
* Fix minor FD leak in journal code. Closes: #754608
  * direct: Fix handling of case where a work tree subdirectory cannot
    be written to due to permissions.
  * migrate: Avoid re-checksumming when migrating from hashE to hash backend.
  * uninit: Avoid failing final removal in some direct mode repositories
    due to file modes.
  * S3: Deal with AWS ACL configurations that do not allow creating or
    checking the location of a bucket, but only reading and writing content to
    it.
  * resolvemerge: New plumbing command that runs the automatic merge conflict
    resolver.
  * Deal with change in git 2.0 that made indirect mode merge conflict
    resolution leave behind old files.
  * sync: Fix git sync with local git remotes even when they don't have an
    annex.uuid set. (The assistant already did so.)
  * Set gcrypt-publish-participants when setting up a gcrypt repository,
    to avoid unncessary passphrase prompts.
    This is a security/usability tradeoff. To avoid exposing the gpg key
    ids who can decrypt the repository, users can unset
    gcrypt-publish-participants.
  * Install nautilus hooks even when ~/.local/share/nautilus/ does not yet
    exist, since it is not automatically created for Gnome 3 users.
  * Windows: Move .vbs files out of git\bin, to avoid that being in the
    PATH, which caused some weird breakage. (Thanks, divB)
  * Windows: Fix locking issue that prevented the webapp starting
    (since 5.20140707).

# imported from the archive
2014-07-17 11:27:25 -04:00

23 lines
1.1 KiB
Markdown

Worked on making the assistant able to merge in existing encrypted
git repositories from rsync.net.
This had two parts. First, making the webapp UI where you click to enable a
known special remote work with these encrypted repos. Secondly, handling
the case where a user knows they have an encrypted repository on rsync.net,
so enters in its hostname and path, but git-annex doesn't know about that
special remote. The second case is important, for example, when the
encrypted repository is a backup and you're restoring from it. It wouldn't
do for the assistant, in that case, to make a *new* encrypted repo and
push it over top of your backup!
Handling that was a neat trick. It has to do quite a lot of probing, including
downloading the whole encrypted git repo so it can decrypt it and merge it,
to find out about the special remote configuration used for it. This all
works with just 2 ssh connections, and only 1 ssh password prompt max.
Next, on to generalizing this rsync.net specific code to work with
arbitrary ssh servers!
----
Today's work was made possible by [RMS's vision 30 years ago](http://article.olduse.net/771@mit-eddie.UUCP).