| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
| |
To prevent any further mistakes like 1a497cefb47557f0b4788c606f9071be422b2511
This commit was sponsored by Francois Marier on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
2f868db90c7ba16eee901b9b1472b1e1a889dd93 changed the Read instance for
Key.
I've checked all uses of that instance (by removing it and seeing what
breaks), and they're all limited to the webapp, except one.
That is GitAnnexDistribution's Read instance.
So, 2f868db90c7ba16eee901b9b1472b1e1a889dd93 would have broken upgrades
of git-annex from downloads.kitenet.net. Once the .info files there got
updated for a new release, old releases would have failed to parse them
and never upgraded.
To fix this, I found a way to make the .info files that contain
GitAnnexDistribution values be readable by the old version of git-annex.
This commit was sponsored by Ewen McNeill.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... to control the default behavior in all clones of a repository.
This includes a new Configurable data type, so the GitConfig type indicates
which values can be configured this way.
The implementation should be quite efficient; the config log is only read
once, and only when a Configurable value has not already been set by
git-config.
Indeed, it would be nice in the future to extend this, so that git-config
is itself only read on demand. Some commands may not need to look at the
git configuration at all.
This commit was sponsored by Trenton Cronholm on Patreon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out that Data.List.Utils.split is slow and makes a lot of
allocations. Here's a much simpler single character splitter that behaves
the same (even in wacky corner cases) while running in half the time and
75% the allocations.
As well as being an optimisation, this helps move toward eliminating use of
missingh.
(Data.List.Split.splitOn is nearly as slow as Data.List.Utils.split and
allocates even more.)
I have not benchmarked the effect on git-annex, but would not be surprised
to see some parsing of eg, large streams from git commands run twice as
fast, and possibly in less memory.
This commit was sponsored by Boyd Stephen Smith Jr. on Patreon.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Docs say vicfg can configure everything from git-annex branch,
so it ought to configure numcopies.
Note that commenting out existing numcopies does not unset it.
This commit was sponsored by Thom May on Patreon.
|
| |
|
|
|
| |
This is a big scary change. I have convinced myself it should be safe. I
hope!
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This sped up git annex find --not --in web from 6.64s to 5.69s.
The optimised parser is probably more like 50% faster than the general one
it replaced.
|
| |
|
|
| |
Avoid orphan instance warning
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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/
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
terminated lines written by some versions of git-annex on Windows.
This fixes strange displays in some cases, including whereis showing
many duplicate locations, and showing more total copies than actually
exist.
It's unknown if that lead to data loss when eg, dropping. At the moment,
it seems unlikely it could, since the UUID with \r's appended is not the
same as a UUID without, and so no remote matches it.
It's also unknown if \r's can leak in on windows, perhaps when merging the
git-annex branch.
|
| |
|
|
| |
avoid redundant work for repeated ForgetDeadRemotes transitions
|
| |
|
|
| |
For example: git-annex reinject --known /mnt/backup/*
|
| |
|
|
|
|
| |
expressions that make sense in its context.
So, not "standard" or "lackingcopies", etc.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
annex.largefiles
This makes git annex clean not look at the git-annex branch at all,
and so speeds it up by 50% or more.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added back with unchanged content.
Implemented with no additional overhead of compares etc.
This is safe to do for presence logs because of their locality of change;
a given repo's presence logs are only ever changed in that repo, or in a
repo that has just been actively changing the content of that repo.
So, we don't need to worry about a split-brain situation where there'd
be disagreement about the location of a key in a repo. And so, it's ok to
not update the timestamp when that's the only change that would be made
due to logging presence info.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
was set to the empty string and the other set to some expression, this bug caused all files to be wanted, instead of only files matching the expression.
Avoid: MAny `MOr` otherexpression
Which matches anything.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I want this as fast as possible, so it can be added to code paths without
slowing them down.
Avoid the set lookup, and rely on laziness,
drops runtime from 14.37 ns to 11.03 ns according to this criterion benchmark:
import Criterion.Main
import qualified Types.Difference as New
import qualified Types.DifferenceOld as Old
main :: IO ()
main = defaultMain
[ bgroup "hasDifference"
[ bench "new" $ whnf (New.hasDifference New.OneLevelObjectHash) new
, bench "old" $ whnf (Old.hasDifference Old.OneLevelObjectHash) old
]
]
where
s = "fromList [ObjectHashLower, OneLevelObjectHash, OneLevelBranchHash]"
new = New.readDifferences s
old = Old.readDifferences s
A little bit of added boilerplate, but I suppose it's worth it to not
need to worry about set lookup overhead. Note that adding more differences
would slow down the old implementation; the new implementation will run
the same speed.
|
| | |
|
| |
|
|
| |
in a bare repo. Otherwise, still reports files with lost contents, even if the content is dead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A dead key is both not present at the location that thinks it has a copy,
and also is assumed to probably not be present anywhere else. Although
there may be lurking disconnected repos that somehow still have a copy.
Suprisingly few changes needed for this! This is because the presence log
code only really concerns itself with keys that are present, and dead keys
are not present.
Note that both the location and web log can be parsed as having a dead key.
I don't see any value to having keys listed as dead in the web log, but
since it doesn't change any behavior, there was no point in not parsing it.
|
| |
|
|
| |
Already b-d on a newer version.
|
| |
|
|
|
| |
Perhaps due to permissions problem, or perhaps a race with another process
also cleaning up.
|
| |
|
|
|
| |
Need to differentiate between the lockfile not being locked, and it not
existing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The one exception is in Utility.Daemon. As long as a process only
daemonizes once, which seems reasonable, and as long as it avoids calling
checkDaemon once it's already running as a daemon, the fcntl locking
gotchas won't be a problem there.
Annex.LockFile has it's own separate lock pool layer, which has been
renamed to LockCache. This is a persistent cache of locks that persist
until closed.
This is not quite done; lockContent stil needs to be converted.
|
| | |
|
| |
|
|
|
|
| |
get/unused/info commands are run.
Deleting lock files is tricky, tricky stuff. I think I got it right!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a little optimisation; avoid loading the info file for the
download of the current key when checking for other downloads.
The reversion it fixes is sorta strange.
b94eafec8c4a7868da753f9b22ca823552e9764c broke checking for transfers
that were already in progress. Indeed, the transfer lock was not held
after getTransfers was called.
Why? I think it's magic in ghc's handling of getLock and setLock,
although it's hard to tell since those functions are almost entirely
undocumented as to their semantics.
Something, either the RTS (or maybe it's linux?) notices that the
same process has taken a lock and is now calling getLock on a FD attached
to the same file. So, it drops the lock.
So, this optimisation avoids that problematic behavior.
|
| |
|
|
| |
annex.diskreserve.
|
| | |
|
| |
|
|
|
| |
The explict import Prelude after import Control.Applicative is a trick
to avoid a warning.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This no longer uses old-locale's defaultTimeLocale, but provides one
of its own.
Factored out a Logs.TimeStamp.
|
| |
|
|
|
| |
I had some cargo culting in there that used the wrong type, so it failed
to parse old logs, and overwrote them with the new log.
|
| |
|
|
| |
This is much more space efficient!
|
Joey Hess