| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
and the assistant add to the annex.
I would have sort of liked to put this in .gitattributes, but it seems
it does not support multi-word attribute values. Also, making this a single
config setting makes it easy to only parse the expression once.
A natural next step would be to make the assistant `git add` files that
are not annex.largefiles. OTOH, I don't think `git annex add` should
`git add` such files, because git-annex command line tools are
not in the business of wrapping git command line tools.
|
| | |
|
| |
|
|
| |
rather buggy.
|
| | |
|
| | |
|
| |
|
|
| |
to install libpcre. Currently done only for Cabal or when the Makefile is made to use -DWITH_GLOB
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various things that don't work on Android are just ifdefed out.
* the webapp (needs template haskell for arm)
* --include and --exclude globbing (needs libpcre, which is not ported;
probably I'll make it use the pure haskell glob library instead)
* annex.diskreserve checking (missing sys/statvfs.h)
* timestamp preservation support (yawn)
* S3
* WebDAV
* XMPP
The resulting 17mb binary has been tested on Android, and it is able to,
at least, print its usage message.
|
| |
|
|
|
|
|
| |
* get/copy --auto: Transfer data even if it would exceed numcopies,
when preferred content settings want it.
* drop --auto: Fix dropping content when there are no preferred content
settings.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
in= was problimatic in two ways. First, it referred to a remote by name,
but preferred content expressions can be evaluated elsewhere, where that
remote doesn't exist, or a different remote has the same name. This name
lookup code could error out at runtime. Secondly, in= seemed pretty useless.
in=here did not cause content to be gotten, but it did let present content
be dropped.
present is more useful, although "not present" is unstable and should be
avoided.
|
| |
|
|
|
|
|
| |
When in a subdir, both the normal filepath, and the filepath relative to
the top of the git repo are needed for matching. The former for key lookup,
and the latter for include/exclude to match against. Previously, key lookup
didn't work in this situation.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Solves the issue with preferred content expressions and dropping that
I mentioned yesterday. My solution was to add a parameter to specify a set
of repositories where content should be assumed not to be present. When
deciding whether to drop, it can put the current repository in, and then
if the expression fails to match, the content can be dropped.
Using yesterday's example "(not copies=trusted:2) and (not in=usbdrive)",
when the local repo is one of the 2 trusted copies, the drop check will
see only 1 trusted copy, so the expression matches, and so the content will
not be dropped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes a full parser for the boolean expressions in the log,
that compiles them into Matchers. Those matchers are not used yet.
A complication is that matching against an expression should never
crash git-annex with an error. Instead, vicfg checks that the expressions
parse. If a bad expression (or an expression understood by some future
git-annex version) gets into the log, it'll be ignored.
Most of the code in Limit couldn't fail anyway, but I did have to make
limitCopies check its parameter first, and return an error if it's bad,
rather than erroring at runtime.
|
| |
|
|
|
|
|
|
|
|
|
| |
repository configuration settings stored in the git-annex branch.
Incomplete; I need to finish parsing and saving. This will also be used
for editing transfer control expresssions.
Removed the group display from the status output, I didn't really
like that format, and vicfg can be used to see as well as edit rempository
group membership.
|
| |
|
|
|
| |
--copies=group:number can now be used to match files that are present in a
specified number of repositories in a group.
|
| |
|
|
| |
specified amount of time.
|
| | |
|
| |
|
|
|
|
|
|
| |
The --copies flag now takes an argument of the form:
trustlevel:number or number
If a trust level is specified the command is limited to files
with at least 'number' copies of this 'trustlevel'.
|
| |
|
|
| |
a stricter (but also partial) readMaybe is getting added to base
|
| |
|
|
| |
A PITA but worth it to clean up the trust configuration code.
|
| | |
|
| |
|
|
| |
content is stored using a specified key-value backend.
|
| |
|
|
|
| |
Apparently in haskell if you teach a man to fish, he'll write
more pointfree code.
|
| |
|
|
| |
no code changes
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
no code changes
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Do not need to check the location log in this case, can just check inAnnex.
This is both an optimisation and perhaps a correctness measure
(fsck --in . should fsck files even if the location log is damaged.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
filterM is not a good idea if you were streaming in a large list of files.
Fixing this memory leak that I introduced earlier today was a PITA because
to avoid the filterM, it's necessary to do the filtering only after
building up the data structures like BackendFile, and that means each
separate data structure needs it own function to apply the filter,
at least in this naive implementation.
There is also a minor performance regression, when using copy/drop/get/fsck
with a filter, git is now asked to look up attributes for all files,
since that now comes before the filter is applied. This is only a very
minor thing, since getting the attributes is very fast and --exclude was
probably not typically used to speed it up.
|
| |
|
|
|
|
|
|
|
| |
find: Rather than only showing files whose contents are present, when used
with --exclude --copies or --in, displays all files that match the
specified conditions.
Note that this is a behavior change for find --exclude! Old behavior
can be gotten with find --in . --exclude=...
|
| |
|
|
|
|
| |
specified number of copies.
(And --not --copies=N for the inverse.)
|
| | |
|
| |
|
|
|
|
|
|
| |
I dislike -( and -), but without using a different option parser, can't
easily use bare parens.
--and and --or will become more useful once there are more interesting
limits than --exclude
|
|
|
This should change no behavior, but opens the poissibility to use the
matcher for other sorts of limits on which files git-annex processes.
|
Joey Hess
Nicolas Pouillard