| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
| |
code melt for lunch
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Mostly only refactoring, but this does remove one redundant stat of the
symlink by copy.
|
| |
|
|
|
|
|
|
|
| |
files that are already present.
This can be a significant speedup when running in large trees that are
only missing a few files; it makes copy --from just as fast as get.
|
|
|
|
|
|
|
|
| |
git-annex-shell inannex now returns always 0, 1, or 100 (the last when
it's unclear if content is currently in the index due to it currently being
moved or dropped).
(Actual locking code still not yet written.)
|
|
|
|
|
|
|
| |
The lock will only persist during the perform stage, so the content must
be removed from the annex then, rather than in the cleanup stage.
(No lock is actually taken yet.)
|
|
|
|
|
|
|
|
|
| |
This new approach allows filtering out checks from the default set that are
not appropriate for a command, rather than having to list every check
that is appropriate. It also reduces some boilerplate.
Haskell does not define Eq for functions, so I had to go a long way around
with each check having a unique id. Meh.
|
| |
|
| |
|
| |
|
|
|
|
| |
no code changes
|
| |
|
| |
|
| |
|
|
|
|
| |
no code changes
|
|
|
|
|
|
|
| |
These were a mistake, they make the type signatures harder to read and
less flexible. The CommandSeek, CommandStart, CommandPerform, and
CommandCleanup types were a good idea, but composing them with the
parameters expected is going too far.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It probably does not make sense to enable auto mode for move. I cannot
think of a situation where it would make sense to try to use it.
A hypothetical auto mode for move would only differ from a normal
move in one case -- when both repositories have a file, move deletes it
from one, and this reduces the number of copies. So an auto mode would
either only let move work in that situation, or avoid removing the file
in that situation, depending on the number of copies. This would be
complex to implement, and is perhaps not a very obvious behavior.
The error is a good thing to have, so users don't expect it to do something
it does not.
|
| |
|
|
|
|
|
| |
And add a simple dots-based progress display, currently only used in v2
upgrade.
|
| |
|
|
|
|
|
| |
Generalized LocationLog to PresenceLog, and use a presence log to record
urls for the web special remote.
|
| |
|
|
|
|
|
| |
Many more commands can work in bare repos now, thanks to the git-annex
branch.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
git when a remote's path contains a symlink. Closes: #621386
This was a real PITA to fix, since location logs can be staged in
both the current repo, as well as in local remote's repos, in
which case the cwd will not be in the repo. And git add needs different
params in both cases, when absolute paths are not used.
In passing, git annex fsck now stages location log fixes.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
--fast. This assumes that location tracking information is correct, rather than contacting the remote for every file.
|
|
|
|
| |
Drop old Remotes.hs, now unused!
|
|
|
|
|
| |
There are two types of commands; those that access the repository and those
that don't. Sorted.
|
|
|
|
| |
doesn't test remote functionality.. but that may be working too now
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
So, I have a type checked safe handling of filenames starting with dashes,
throughout the code.
|
|
|
|
|
| |
Due to recent changes, the remotes config was not read before the remote
to act on was picked.
|
|
|
|
| |
And a bug fix in passing.
|
| |
|
|
|
|
|
|
|
| |
Moved away from a map of flags to storing config directly in the AnnexState
structure. Got rid of most accessor functions in Annex.
This allowed supporting multiple --exclude flags.
|
|
|
|
| |
Most of it was to do with managing annexed Content, so put there
|
|
|
|
| |
it from local.
|
|
|
|
|
|
|
|
|
| |
* bugfix: Running `move --to` with a remote whose UUID was not yet known
could result in git-annex not recording on the local side where the
file was moved to. This could not result in data loss, or even a
significant problem, since the remote *did* record that it had the file.
* Also, add a general guard to detect attempts to record information
about repositories with missing UUIDs.
|
| |
|
| |
|