| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
| |
the local tree.
Observed that the pushed refs were received, but not merged into master.
The merger never saw an add event for these refs. Either git is not writing
to a new file and renaming it into place, or the inotify code didn't notice
that. Changed it to also watch for modify events and that seems to have
fixed it!
|
|
|
|
|
|
|
|
|
| |
Note that the note on d12b1fb179bc1744f813ea3f616d503d2b0dfe09 turned out
to be wrong. Multiple repository pairing over XMPP does work, because the
annex-uuid of the xmpp remote is updated to the uuid of the new repo
when pairing takes place. So the push from it is accepted. (And the other
UUIDs are listed in uuid.log, so pushes from those repositories also are
accepted of course.)
|
| |
|
| |
|
|
|
|
| |
creating a new remote of the same type. Done for Internet Archive, S3, Glacier, and Box.com remotes.
|
|
|
|
| |
used. The initremote command now is used only to create new special remotes.
|
| |
|
| |
|
| |
|
|
|
|
| |
indicates it does. Always refuse to drop from there.
|
|
|
|
|
|
|
| |
* Add public repository group.
* webapp: Can now set up Internet Archive repositories.
TODO: Enabling IA repositories.
|
|
|
|
| |
a higher trust level.
|
| |
|
| |
|
| |
|
|
|
|
| |
fails to run git-annex-shell.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filesystems.
The root of the problem is that toInodeCache sees a non-symlink, and so
goes on and generates a new inode cache for the dummy symlink.
Any place that toInodeCache, or sameFileStatus, or genInodeCache are called
may need to deal with this case. Although many of them are ok. For example,
prepSendAnnex calls sameInodeCache, which calls genInodeCache.. but if
the file content is not present, the InodeCache generated for its standin
file is appropriately not the same, and so it returns Nothing.
I've audited some, but have to say I'm not happy with this; it should be
handled at the type level somehow, or a toInodeCache wrapper be used that
is aware of dummy symlinks.
(The Watcher already dealt with it, via the guardSymlinkStandin function.)
|
| |
|
|
|
|
| |
remote. Newer git uses `git remote remove`.
|
|
|
|
| |
watch daemon is running.
|
|
|
|
| |
repository already exists as a non-bare repository, use it, rather than initializing a bare repository in the same directory.
|
|
|
|
| |
user.name set in git config, and put in a workaround so that commits to the git-annex branch (and the assistant) will still succeed despite git not liking the system configuration.
|
|
|
|
|
|
|
|
| |
This is so git remotes on servers without git-annex installed can be used
to keep clients' git repos in sync.
This is a behavior change, but since annex-sync can be set to disable
syncing with a remote, I think it's acceptable.
|
|
|
|
| |
directory containing a git-annex file (eg, standalone tarball directory).
|
| |
|
|
|
|
|
|
| |
--alow-empty -m ""` run an editor.
See http://git-annex.branchable.com/bugs/assistant_hangs_during_commit/
|
| |
|
| |
|
|
|
|
|
|
|
| |
they are unmodified).
I wrote this earlier, but it never worked because it was looking at the
.git/annex/object content, which is not there..
|
| |
|
| |
|
|
|
|
| |
name, so that a locked down ssh key for one repository is not re-used when setting up additional repositories on the same server.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
assistant: Work around horrible, terrible, very bad behavior of
gnome-keyring, by not storing special-purpose ssh keys in ~/.ssh/*.pub.
Apparently gnome-keyring apparently will load and indiscriminately use such
keys in some cases, even if they are not using any of the standard ssh key
names. Instead store the keys in ~/.ssh/annex/, which gnome-keyring will
not check.
Note that neither I nor #debian-devel were able to quite reproduce this
problem, but I believe it exists, and that this fixes it. And it certianly
won't hurt anything..
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most remotes have meters in their implementations of retrieveKeyFile
already. Simply hooking these up to the transfer log makes that information
available. Easy peasy.
This is particularly valuable information for encrypted remotes, which
otherwise bypass the assistant's polling of temp files, and so don't have
good progress bars yet.
Still some work to do here (see progressbars.mdwn changes), but this
is entirely an improvement from the lack of progress bars for encrypted
downloads.
|
|
|
|
|
|
| |
* addurl: Register transfer so the webapp can see it.
* addurl: Automatically retry downloads that fail, as long as some
additional content was downloaded.
|
| |
|
|
|
|
|
|
| |
symlinks on FAT and other filesystem not supporting symlinks.
also, blog for the day..
|
|
|
|
|
|
|
| |
For backwards compatability, "" is treated as "0" sequence number.
--debug will show xmpp sequence numbers now, but they are not otherwise
used.
|
| |
|
| |
|
|
|
|
| |
VERSION_FROM_CHANGELOG.
|
| |
|
| |
|
|
|
|
|
|
|
| |
connecting to it from another.
Does not yet use HTTPS. I'd need to generate a certificate, and I'm not
sure what's the best way to do that.
|
| |
|
|
|
|
|
| |
Adjust preferred content expressions so that content in archive directories
is preferred until it has reached an archive or smallarchive repository.
|