| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
gets synced.
|
| |
|
|
|
| |
One reason to do this is that on OSX, it doesn't jump to the web browser
when opening a new page. Linux seems ahead in usability here... :P
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If the autostart file lists a repository, for which a directory exists,
but there's not actually a valid git repo in there, the web app used to
try to use it, and see it wasn't valid, and then try to autostart again.
The ensuing runaway loop also ate memory, although not as fast as I was led
to belive was happening to someone on IRC yesterday. So that guy may have
had a different problem. But this seems otherwise a reasonable fit for the
circumstances described, if git-annex was started before something that
occurred during desktop login that made the repository available.
|
| |
|
|
| |
This is less expensive than having inallgroup weed out dead repositories.
|
| |
|
|
|
|
|
|
|
| |
Both when queueing downloads, and uploads, consults the preferred content
settings.
I didn't make it check yet when requeing failed transfers or queuing
deferred downloads; dealing with the preferred content settings (or indeed,
other settings) changing while the assistant is running still needs work.
|
| |
|
|
|
| |
this should make it easy to use from inside the assistant, where
everything is an AssociatedFile.
|
| | |
|
| |
|
|
|
| |
With --from, it needs to examine the preferred content of the repository
being dropped from, instead of the local repository.
|
| | |
|
| |
|
|
|
| |
Made Git.LsFiles return cleanup actions, and everything waits on
processes now, except of course for Seek.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm down to 9 places in the code that can produce unwaited for zombies.
Most of these are pretty innocuous, at least for now, are only
used in short-running commands, or commands that run a set of
actions and explicitly reap zombies after each one.
The one from Annex.Branch.files could be trouble later,
since both Command.Fsck and Command.Unused can trigger it,
and the assistant will be doing those eventally. Ditto the one in
Git.LsTree.lsTree, which Command.Unused uses.
The only ones currently affecting the assistant though, are
in Git.LsFiles. Several threads use several of those.
(And yeah, using pipes or ResourceT would be a less ad-hoc approach,
but I don't really feel like ripping my entire code base apart right
now to change a foundation monad. Maybe one of these days..)
|
| |
|
|
|
|
| |
Nearly everything that's reading from git is operating on a small
amount of output and has been switched to use that. Only pipeNullSplit
stuff continues using the lazy version that yields zombies.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
One note: Deleted lines are not currently parsed as config changes.
That makes sense for trust settings. It may make sense to support deleted
lines as a way to clear group settings.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
monthly incremental fsck runs in cron jobs.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Simplified it using existing functions.
I doubt setSticky needs to return the FileMode; if it does for some
reason, it can be changed to use modifyFileMode'
Converted isSticky to a pure function for consistency with isSymlink.
Note that the sticky bit of a file can be tested thus:
isSticky . fileMode <$> getFileStatus file
|
| | |
|
| |
|
|
| |
Not yet used..
|
| |
|
|
|
| |
git annex copy --to remote often does not need to copy a file,
but it was still updating the location log in this case.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Fix resuming of downloads, which do not have a transfer info file to read.
When checking upload progress, use the MVar, rather than re-reading
the info file.
Catch exceptions in the transfer action. Required a tryAnnex.
|
| |
|
|
|
|
|
| |
When a transfer fails, the progress info can be used to intelligently
retry it. If the transfer managed to make some progress, but did not
fully complete, then there's a good chance that a retry will finish it
(or at least make more progress).
|
| |
|
|
| |
git config --list --global exits nonzero when there's no global config
|
| |
|
|
| |
Finally done with progressbars!
|
| |
|
|
|
| |
TODO: Use this when running sendkey, to feed back transfer info from the
client side rsync.
|
| | |
|
| |
|
|
|
| |
Can't use show-ref --tags --branches, as that omits remote branches.
Instead, filter out the synced refs directly.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Transfer info files are updated when the callback is called, updating
the number of bytes transferred.
Left unused p variables at every place the callback should be used.
Which is rather a lot..
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't expose these as branches in refs/heads/. Instead hide them away in
refs/synced/ where only show-ref will find them.
Make unused only look at branches and tags, not these other things,
so it won't care if some stale sync ref used to use a file.
This means they don't need to be deleted, which could have
led to an incoming sync being missed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
directly to remote/git-annex.
This fixes a problem I was seeing in the assistant where two remotes would
attempt to sync with one another at the same time, and both failed pushing
the diverged git-annex branch. Then when both tried to resolve the failed
push, they each modified their git-annex branch, which again each blocked
the other from pushing into it. The result was that the git-annex
branches were perpetually diverged (despite having the same content!) and
once the assistant fell into this trap, it couldn't get out and always
had to do the slow push/fail/pull/merge/push/fail cycle.
|
| |
|
|
| |
than moving to .git/annex/bad/
|
| | |
|
| |
|
|
| |
key for corrupt data.
|
Joey Hess
Joey Hess