| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
been dropped.
Before it crashed trying to lock the not-present content and prevented
dropping anything else. Instead, succeed.
|
| |
|
|
|
|
|
|
|
| |
content of the url is downloaded. (Not when using --fast or --relaxed.)
importfeed just calls addurl functions, so inherits this from it.
Note that addurl still generates a temp file, and uses that key to download
the file. It just adds it to the work tree at the end when the file is small.
|
| | |
|
| |
|
|
| |
gcrypt.
|
| | |
|
| |
|
|
|
| |
Including in addurl, and get --from web, but also in S3 and External
special remotes when a web url is known for content in those remotes.
|
| | |
|
| |
|
|
|
| |
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.
|
| |
|
|
| |
import -J
|
| |
|
|
|
|
| |
of the annex back to the file, because other files may point to that same content. Instead, copy the injected file content out to recover.
That was not a data loss, but it came close!
|
| | |
|
| | |
|
| |
|
|
| |
to is not a directort, but perhaps an annexed file.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Commands that want to use it have to run their seek action inside
allowConcurrentOutput. Which seems reasonable; perhaps some future command
will want to support the -J flag but not use regions.
The region state moved from Annex to MessageState. This makes sense
organizationally, and note that some uses of onLocal use a different Annex
state, but pass the MessageState into it, which is what is needed.
|
| |
|
|
| |
and accept either the uuid or the description in leu if the name.
|
| | |
|
| |
|
|
|
|
|
|
| |
sideAction is for things not generally related to the current action being
performed. And, it adds a newline after the side action. This was not the
right thing to use for stuff like "checksum", where doing a checksum is
part of the git annex get process, and indeed we want it to display
"(checksum...) ok"
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
local copy be locked for removal
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
There should be no behavior changes in this commit, it just adds a more
expressive data type and adjusts code that had been passing around a [UUID]
or sometimes a Maybe Remote to instead use [VerifiedCopy].
Although, since some functions were taking two different [UUID] lists,
there's some potential for me to have gotten it horribly wrong.
|
| |
|
|
|
| |
Not implemented for any remotes yet; probably the git remote is the only
one that will ever implement it.
|
| |
|
|
| |
content.
|
| |
|
|
|
|
|
|
| |
Also, rename lockContent to lockContentExclusive
inAnnexSafe should perhaps be eliminated, and instead use
`lockContentShared inAnnex`. However, I'm waiting on that, as there are
only 2 call sites for inAnnexSafe and it's fiddly.
|
| |
|
|
| |
checking what --to should, and vice-versa.) Fixed this bug, which was introduced in version 5.20150727.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* When annex objects are received into git repositories, their checksums are
verified then too.
* To get the old, faster, behavior of not verifying checksums, set
annex.verify=false, or remote.<name>.annex-verify=false.
* setkey, rekey: These commands also now verify that the provided file
matches the key, unless annex.verify=false.
* reinject: Already verified content; this can now be disabled by
setting annex.verify=false.
recvkey and reinject already did verification, so removed now duplicate
code from them. fsck still does its own verification, which is ok since it
does not use getViaTmp, so verification doesn't happen twice when using fsck
--from.
|
| | |
|
| |
|
|
| |
No behavior changes.
|
| |
|
|
|
|
|
|
|
|
|
| |
Seems easy, but git ls-files can't list the right subset of files.
So, I wrote a whole new parser for git status output, and converted the
status command to use that.
There are a few other small behavior changes. The order changed. Unlocked
files show as T. In indirect mode, deleted files were not shown before, and
that's fixed. Regular files checked directly into git and modified
were not shown before, and are now.
|
| | |
|
| |
|
|
|
|
|
| |
git-annex branch and would create it if it were missing.
I made the change to allow in 2014 without any rationalle or associated
request that I can find.
|
| |
|
|
| |
enabled when git-annex init is run.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
sync process, as well as supporting --commit, --pull, --push, and --no-content options to specify the (current) default behavior.
|
| |
|
|
|
|
| |
Fix typo in commit aa96e9c ("convert Unused, and remove some dead code
for old style option parsing", 2015-07-10), the "git-annex unused
--used-refspec" option was incorrectly changed to --unused-refspec.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
It's the default, but this is a step toward changing that default later..
|
Joey Hess
Øyvind A. Holm
Ben Boeckel