| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
Added --json-error-messages option, which includes error messages in the
json output, rather than outputting them to stderr.
The actual rediretion of errors is not implemented yet, this is only
the docs and option plumbing.
This commit was supported by the NSF-funded DataLad project.
|
| |
|
|
| |
Avoid reading location log in this case.
|
| |
|
|
|
|
| |
requires it.
This commit was sponsored by Jack Hill on Patreon.
|
| |
|
|
|
|
|
|
|
|
| |
did not take the core.sharedRepository config into account.
git grep writeFile finds some more that might also be problems, but
for now I've concentrated on .git/annex/ log files. There are certianly
cases where writeFile is not a problem too.
This commit was sponsored by mo on Patreon.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Clean up some uses of showStart with "" for the file,
or in some cases, a non-filename description string. That would
generate bad json, although none of the commands doing that
supported --json.
Using "" for the file resulted in output like "foo rest";
now the extra space is eliminated.
This commit was sponsored by Fernando Jimenez on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
| |
git annex add, git annex lock etc make multiple seek passes,
and each seek pass checked that files existed. That was unncessary
redundant work.
Fixed by adding a new WorkTreeItem type, make seek actions use it,
and check that the files exist when constructing it.
This commit was supported by the NSF-funded DataLad project.
|
| |
|
|
|
|
|
| |
One use case is to get a list of files that fsck fails on, in order to eg,
drop them from a remote.
This commit was sponsored by Nick Daly on Patreon.
|
| |
|
|
|
|
|
|
| |
Reworked remote name parsing to allow things like that. Command.Move
uses it for --to=here, although there's not yet an implementation of
that option.
This commit was sponsored by Ignacio on Patreon.
|
| | |
|
| |
|
|
|
| |
This changes fsck -A warnings to include the name of the key,
which is a bit redundant in one case, but was missing in another case.
|
| |
|
|
|
|
| |
To prevent any further mistakes like 1a497cefb47557f0b4788c606f9071be422b2511
This commit was sponsored by Francois Marier on Patreon.
|
| |
|
|
|
| |
Got two Maybe FilePaths crossed. Test suite caught it.
Slightly improved types to avoid this mistake.
|
| |
|
|
|
|
| |
warning message.
This commit was sponsored by Alexander Thompson on Patreon.
|
| |
|
|
|
|
| |
collisions with git-annex
This commit was sponsored by andrea rota.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Where before the "name" of a key and a backend was a string, this makes
it a concrete data type.
This is groundwork for allowing some varieties of keys to be disabled
in file2key, so git-annex won't use them at all.
Benchmarks ran in my big repo:
old git-annex info:
real 0m3.338s
user 0m3.124s
sys 0m0.244s
new git-annex info:
real 0m3.216s
user 0m3.024s
sys 0m0.220s
new git-annex find:
real 0m7.138s
user 0m6.924s
sys 0m0.252s
old git-annex find:
real 0m7.433s
user 0m7.240s
sys 0m0.232s
Surprising result; I'd have expected it to be slower since it now parses
all the key varieties. But, the parser is very simple and perhaps
sharing KeyVarieties uses less memory or something like that.
This commit was supported by the NSF-funded DataLad project.
|
| |
|
|
|
|
|
|
| |
rather than on the special remote.
Straight up forgot to handle this case!
This commit was sponsored by Fernando Jimenez on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
backtraces for unexpected errors.
ghc 8 added backtraces on uncaught errors. This is great, but git-annex was
using error in many places for a error message targeted at the user, in
some known problem case. A backtrace only confuses such a message, so omit it.
Notably, commands like git annex drop that failed due to eg, numcopies,
used to use error, so had a backtrace.
This commit was sponsored by Ethan Aubin.
|
| |
|
|
|
|
|
|
|
| |
Note that get --from foo --failed will get things that a previous get --from bar
tried and failed to get, etc. I considered making --failed only retry
transfers from the same remote, but it was easier, and seems more useful,
to not have the same remote requirement.
Noisy due to some refactoring into Types/
|
| |
|
|
|
|
|
|
| |
Show branch:file that is being operated on.
I had to make ActionItem a type and not a type class because
withKeyOptions' passed two different types of values when using the type
class, and I could not get the type checker to accept that.
|
| |
|
|
| |
location log thinks it is not. Reversion introduced in version 5.20151208.
|
| |
|
|
| |
something so that reinject --known will work.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
write bit is not set and cannot be set due to the file being owned by a different user.
Made all Annex.Perms file mode changing functions ignore errors when
core.sharedRepository is set, because the file might be owned by someone
else. I don't fancy getting bug reports about crashes due to set modes in
this configuration, which is a very foot-shooty configuration in the first
place.
The fsck warning is necessary because old repos kept files mode 444, which
doesn't allow locking them, and so if the mode remains 444 due to the file
being owned by someone else, the user should be told about it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
When annex.thin is set, adding an object will add the execute bits to the
work tree file, and this does mean that the annex object file ends up
executable.
This doesn't add any complexity that wasn't already present, because git
annex add of an executable file has always ingested it so that the annex
object ends up executable.
But, since an annex object file can be executable or not, when populating
an unlocked file from one, the executable bit is always added or removed
to match the mode of the pointer file.
|
| |
|
|
| |
repository.
|
| |
|
|
|
|
| |
annex/objects but didn't reach the work tree.
This also handles fixing up after f9dfeaf801da2e4d5879b3de5895dc3cef68a329
|
| |
|
|
|
| |
This also handles fixing up after the bad data written by
f9dfeaf801da2e4d5879b3de5895dc3cef68a329.
|
| |
|
|
| |
When on crippled filesystem, or without annex.thin set.
|
| | |
|
| | |
|
| |
|
|
| |
needs it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This only adds 1 stat to each file fscked for locked files, so
added overhead is minimal.
For unlocked files it has to access the database to see if a file
is modified.
|
| | |
|
| | |
|
| |
|
|
|
| |
keyLocations doesn't return locations in dead repos, but if we're fscking a
dead repo, we want to look at what locations are actually logged for it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In c3b38fb2a075b4250e867ebd910324c65712c747, it actually only handled
uploading objects to a shared repository. To avoid verification when
downloading objects from a shared repository, was a lot harder.
On the plus side, if the process of downloading a file from a remote
is able to verify its content on the side, the remote can indicate this
now, and avoid the extra post-download verification.
As of yet, I don't have any remotes (except Git) using this ability.
Some more work would be needed to support it in special remotes.
It would make sense for tahoe to implicitly verify things downloaded from it;
as long as you trust your tahoe server (which typically runs locally),
there's cryptographic integrity. OTOH, despite bup being based on shas,
a bup repo under an attacker's control could have the git ref used for an
object changed, and so a bup repo shouldn't implicitly verify. Indeed,
tahoe seems unique in being trustworthy enough to implicitly verify.
|
| |
|
|
| |
No behavior changes.
|
| |
|
|
|
|
|
|
|
| |
appropriate places.
Not necessarily everywhere, but a lot of the most often used places.
Re the use of .Internal, see
https://github.com/pcapriotti/optparse-applicative/issues/155
|
| |
|
|
|
|
|
|
| |
Ben Boeckel had a patch, but..
Actually, that was not the only place that used ScheduleIncremental when
built w/o database. Since the data type doesn't need database stuff,
I've instead fixed this build problem by exposing the
ScheduleIncremental constructor to database-less builds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Perform a clean shutdown when --time-limit is reached.
This includes running queued git commands, and cleanup actions normally
run when a command is finished.
* fsck: Commit incremental fsck database when --time-limit is reached.
Previously, some of the last files fscked did not make it into the
database when using --time-limit.
Note that this changes Annex.addCleanup hooks, to run after --time-limit
expires. Fsck was using such a hook to clean up after a
--incremental-schedule, and that shouldn't run when --time-limit exipires
it. So, instead, moved that cleanup code to be run by cleanupIncremental.
Resulted in some data type juggling.
|
| |
|
|
| |
This removes support for incremental fsck.
|
| | |
|
| | |
|
| |
|
|
| |
Got a little tricky..
|
| | |
|
| | |
|
Joey Hess