| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
| |
user.name set in git config, and put in a workaround so that commits to the git-annex branch (and the assistant) will still succeed despite git not liking the system configuration.
|
| |
|
|
|
| |
I've found multiple references to using the `am` command from the adb shell
to open a browser. So I assume it also works in a terminal emulator.
|
| |
|
|
|
|
|
| |
connecting to it from another.
Does not yet use HTTPS. I'd need to generate a certificate, and I'm not
sure what's the best way to do that.
|
| | |
|
| |
|
|
| |
Not yet used .. mindless train work.
|
| |
|
|
| |
runtime, as well as configuring numcopies and diskreserve.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
It used to not log to daemon.log when a repository was first created, and
when starting the webapp. Now both do. Redirecting stdout and stderr to the
log is tricky when starting the webapp, because the web browser may want to
communicate with the user. (Either a console web browser, or web.browser = echo)
This is handled by restoring the original fds when running the browser.
|
| |
|
|
|
|
| |
This avoids some small overhead by only running the check once per command;
it also ensures that, even if the command doesn't find anything to run on,
it still fails to run when in a bare repo.
|
| | |
|
| |
|
|
|
|
| |
variables before running the system web browser.
Should fix a crash reported on OSX.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This adds the Assistant monad, and an AssistantData structure.
So far, none of the assistant's threads run in the monad yet.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I now have this topology working:
assistant ---> {bare repo, special remote} <--- assistant
And, I think, also this one:
+----------- bare repo --------+
v v
assistant ---> special remote <--- assistant
While before with assistant <---> assistant connections, both sides got
location info updated after a transfer, in this topology, the bare repo
*might* get its location info updated, but the other assistant has no way to
know that it did. And a special remote doesn't record location info,
so transfers to it won't propigate out location log changes at all.
So, for these to work, after a transfer succeeds, the git-annex branch
needs to be pushed. This is done by recording a synthetic commit has
occurred, which lets the pusher handle pushing out the change (which will
include actually committing any still journalled changes to the git-annex
branch).
Of course, this means rather a lot more syncing action than happened
before. At least the pusher bundles together very close together pushes,
somewhat. Currently it just waits 2 seconds between each push.
|
| | |
|
| |
|
|
|
| |
It's possible for the file to get duplicate lines in it, and if so, we want
to ignore the dups.
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
| |
git config --list --global exits nonzero when there's no global config
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
They work fine. But I had to go to a lot of trouble to get Yesod to render
routes in a pure function. It may instead make more sense to have each
alert have an assocated IO action, and a single route that runs the IO
action of a given alert id. I just wish I'd realized that before the past
several hours of struggling with something Yesod really doesn't want to
allow.
|
| | |
|
| |
|
|
|
| |
Currently waits for a new transfer slot to open up, which probably needs to
change..
|
| | |
|
| |
|
|
| |
remote setup still todo
|
| |
|
|
|
|
|
|
| |
git annex assistant --autostart will start separate daemons in each
listed autostart repo
running the webapp outside any git-annex repo will open it on the
first listed autostart repo
|
| |
|
|
| |
Remove --foreground and --stop options from it.
|
| | |
|
| |
|
|
|
|
|
|
| |
This prevents multiple runs of the assistant in the foreground, and lets
--stop stop foregrounded runs too.
The webapp firstrun case also now writes a pid file, once it's made the git
repo to put it in.
|
| |
|
|
| |
Some of the trickiest code I've possibly ever written.
|
| |
|
|
| |
My $HOME is in git, let's make it work :)
|
| |
|
|
|
| |
Maybe later it can prompt if they want to use the repo with git-annex, but
for now this is a sane easy choice.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This avoids forking another process, avoids polling, fixes a race,
and avoids a rare forkProcess thread hang that I saw once time
when starting the webapp.
|
| |
|
|
| |
I've seen 10 be too short under load.
|
| |
|
|
|
|
| |
the pid file
fixes a possible race
|
| | |
|
| |
|
|
| |
--force could enable other, unwanted behavior
|
| |
|
|
| |
Useful for testing..
|
| | |
|
|
|
Also, starts the assistant if it wasn't already running.
|
Joey Hess
Joey Hess