e213ef310f
* 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
22 lines
1.2 KiB
Markdown
22 lines
1.2 KiB
Markdown
Still working on the git repair code. Improved the test suite, which found
|
|
some more bugs, and so I've been running tests all day and occasionally
|
|
going and fixing a bug in the repair code. The hardest part of repairing a
|
|
git repo has turned out to be reliably determining which objects in it are
|
|
broken. Bugs in git don't help (but the git devs are going to fix the one I
|
|
reported).
|
|
|
|
But the interesting new thing today is that I added some upgrade alert code
|
|
to the webapp. Ideally everyone would get git-annex and other software as
|
|
part of an OS distribution, which would include its own upgrade system --
|
|
But the [survey](http://git-annex-survey.branchable.com/polls/2013/how_installed/)
|
|
tells me that a quarter of installs are from the prebuilt binaries I
|
|
distribute.
|
|
|
|
So, those builds are going to be built with knowledge of an upgrade url,
|
|
and will periodically download a small info file (over https) to see if a
|
|
newer version is available, and show an alert.
|
|
|
|
I think all that's working, though I have not yet put the info files in
|
|
place and tested it. The actual upgrade process will be a manual
|
|
download and reinstall, to start with, and then perhaps I'll automate it
|
|
further, depending on how hard that is on the different platforms.
|