| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
destination's default file permissions, as the local ones can be arbitrarily broken. (Ie, ----rwxr-x for files on Android)
|
| |
|
|
|
|
| |
Run the same code git-annex used to get the sha, including its sanity
checking. Much better than old grep. Should detect FreeBSD systems with
sha commands that output in stange format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
appears to be a real sha.
This after fielding a bug where git-annex was built with a sha256 program
whose output checked out, but was then run with one that output lines
like:
SHA256 (file) = <sha here>
Which it then parsed as having a SHA256 of "SHA256"!
Now the output of the command is required to be of the right length,
and contain only the right characters.
|
| |
|
|
| |
from some Android devices may have very broken permissions as received.
|
| |
|
|
|
|
|
| |
is made absolute.
Using a relative path would work, until the user changed to some other
directory in the repo and tried to access the remote from there..
|
| |
|
|
|
|
|
|
|
| |
It's possible for files in indirect mode to have a direct mode mapping
file. Probably from when they were in direct mode. In this case,
toDirectGen tried to copy the content from the direct mode file that the
mapping said had it. But, being in indirect mode, it didn't really have the
content. So it did nothing. This fix makes it always move the content from
.git/annex/objects/ when it's there.
|
| |
|
|
| |
build.
|
| | |
|
| |
|
|
| |
built. This may fix builds on s390x and sparc, which are failing to link -lHSrts_thr
|
| |
|
|
| |
with, since yesod 1.2 has a great many changes that will require extensive work on the webapp.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
Joey Hess