| Commit message (Collapse) | Author | Age |
|
|
|
| |
needs time and space optimisation
|
| |
|
|
|
|
| |
split into generic IO code, and a thin Annex wrapper
|
| |
|
| |
|
|\ |
|
| |
| |
| |
| | |
This parser should be fast. I hope.
|
| |
| |
| |
| | |
Should be faster here.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Different keys can have the same size, so can't make a Set of the sizes.
This version actually runs faster yet, too..
|
|
|
|
|
|
|
|
|
|
| |
Using Sets is the right thing; they have constant size lookup like my
SizeList, and logn insertation, which beats nub to death.
Runs faster than --fast mode did before, and gives accurate counts.
13 seconds total runtime with a warm cache in a repository with 40 thousand
keys.
|
|
|
|
| |
only approximate, and is marked as such.
|
| |
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
|
|
| |
Only one place need to filter the list of remotes for ignored remotes:
keyPossibilities. Make the full list available to everything else.
This allows getting rid of the special case handing for --from and --to
to make ignored remotes not be ignored with those options.
|
|
|
|
| |
(--in is not yet implemented)
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
needs
Especially handy for running a match monadically.
|
| |
|
| |
|