| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
Joey Hess