| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Since the queue is flushed in between subcommand actions being run,
there should be no issues with actions that expect to queue up some stuff
and have it run after they do other stuff. So I didn't have to audit for
such assumptions.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Conflicts:
debian/changelog
|
| | |
| |
| |
| | |
permissions.
|
| |/ |
|
| |
|
|
| |
--fast. This assumes that location tracking information is correct, rather than contacting the remote for every file.
|
| |
|
|
| |
Drop old Remotes.hs, now unused!
|
| | |
|
| |
|
|
| |
only move and map still to convert
|
| | |
|
| |
|
|
| |
that can be used for free space checking.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
already present in .git/annex/objects.
For example, this could happen if using SHA1 and a file with content
"foo" were added to that backend. Then a file with "content" foo were
migrated from the WORM backend.
Assume that, if a backend assigned the same key, the already annexed
content must be the same. So, the "old" content can be reused.
|
| |
|
|
| |
temp files are always assumed to be unused, in either mode
|
| |
|
|
|
|
|
|
|
|
| |
Add --fast flag, that can enable less expensive, but also less thurough versions of some commands.
* Add --fast flag, that can enable less expensive, but also less thurough
versions of some commands.
* fsck: In fast mode, avoid checking checksums.
* unused: In fast mode, just show all existing temp files as unused,
and avoid expensive scan for other unused content.
|
| |
|
|
|
|
|
|
| |
Free space checking is now done, for transfers of data for keys that have free space metadata.
(Notably, not for SHA* keys generated with git-annex 0.24 or earlier.)
The code is believed to work on Linux, FreeBSD, and OSX; check compile-time
messages to see if it is not enabled for your OS.
|
| | |
|
| | |
|
| |
|
|
|
| |
There are two types of commands; those that access the repository and those
that don't. Sorted.
|
| | |
|
| |
|
|
| |
etc. Use git-annex upgrade when you're ready to run this version.
|
| |
|
|
| |
information.
|
| | |
|
| | |
|
| |
|
|
| |
doesn't test remote functionality.. but that may be working too now
|
| | |
|
| |
|
|
| |
key is now specified as the full key, no --backend needed
|
| | |
|
| |
|
|
|
|
|
| |
It compiles. It sorta works. Several subcommands are FIXME marked and
broken, because things that used to accept separate --backend and --key
params need to be changed to accept just a --key that encodes all the key
info, now that there is metadata in keys.
|
| | |
|
| |
|
|
|
|
|
| |
When adding files to the annex, the symlinks pointing at the annexed
content are made to have the same mtime as the original file. While git
does not preserve that information, this allows a tool like metastore to be
used with annexed files.
|
| |
|
|
| |
or may not match locale settings, any attempt to decode filenames will fail for some files. So instead, do all output in binary mode.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Most will just abort. init does a basic init and gives a command to
run elsewhere to finish it.
|
| |
|
|
|
| |
Since they need to stage changes, they would actually, if allowed to run,
succeed, but wipe out existing trust.log content.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This assumes that changes to content in bare repos are made from some
non-bare repo, and that the location log is updated on that side.
That's true for move --from and move --to.
It's *not* true for dropkey and setkey and recvkey. But those are plumbing
level commands, so I guess it's ok to assume that someone running those
in a bare repo knows what they're doing. And git-annex-shell is used to
run those, and if the bare repo is non-local, it needs to be able to use
them even though they cannot update the location log. So this seems
unavoidable.
|
| | |
|
| | |
|
Joey Hess