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