| Commit message (Collapse) | Author | Age |
|
|
|
| |
rather than the default of considering all refs used.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
get/unused/info commands are run.
Deleting lock files is tricky, tricky stuff. I think I got it right!
|
|
|
|
|
| |
This affected callers that used forwardRetry; if the 1st attempt failed it
would clean up the transfer lock before retrying.
|
|
|
|
|
|
| |
running at once.
As discussed in bug report.
|
|
|
|
|
|
|
|
| |
Should be no behavior changes, just simplified code.
The only actual difference is it doesn't truncate the lock file.
I think that was a holdover from when transfer info was written to the lock
file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
used.
Only the assistant uses these, and only the assistant cleans them up, so
make only git annex transferkeys write them,
There is one behavior change from this. If glacier is being used, and a
manual git annex get --from glacier fails because the file isn't available
yet, the assistant will no longer later see that failed transfer file and
retry the get. Hope no-one depended on that old behavior.
|
|
|
|
| |
annex.diskreserve.
|
| |
|
|
|
|
| |
No progress bars with -J unless built with ascii-progress.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Command/Fsck.hs
Messages.hs
Remote/Directory.hs
Remote/Git.hs
Remote/Helper/Special.hs
Types/Remote.hs
debian/changelog
git-annex.cabal
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
| |
| |
| | |
not make sense and could cause data loss.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Moved rules out of debian/rules and avoided need for patching it for
standalone builds
|
| |\ |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
7.10
|
| | |
|
| |
| |
| |
| | |
merely a difference of opinion to you to do this is a bit of an asshole move. Just saying.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This is certianly a cabal bug for not passing the build options in the
cabal file when building Setup.hs.
And, why oh why did ghc enable this warning by default? So unhappy with
this choice.
|
| | |
|
| |
| |
| |
| |
| | |
The explict import Prelude after import Control.Applicative is a trick
to avoid a warning.
|
| | |
|
| | |
|
| |
| |
| |
| | |
when using OverloadedStrings
|