| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
This reverts commit 733a90bbd382683fa788aa6949f0fac11ba6504b.
The stderr fd is also trashed after `am` fails to open the web browser.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Avoid using dupped stderr, since
http://git-annex.branchable.com/bugs/warning_-_WebApp_crashed:___60__file_descriptor_15__62__:_hPutStr:_illegal_operation___40__handle_is_closed__41___on_Android/#comment-a24c73803fb10bd35afdc10d50e071c8
seems to involve that handle not being dupped originally, or perhaps
getting closed when the web browser is started on Android.
Using the dupped stdout is known to work before starting the web browser,
so it should work after -- unless perhaps starting it closes both handles.
In any case, there's no real need to write to stderr here.
|
| |
|
|
| |
Android devices that cannot auto-open the webapp on start.
|
| |
|
|
| |
Still need to git rm the old file so git accepts the merge is resolved.
|
| |
|
|
|
| |
588a981e17461643b67f9a372703b9e0896b6e17's fix caused it to try to stage a
symlink in .git/annex/tmp, oops
|
| |
|
|
|
|
|
| |
Ie, when there'a a conflicted merge we may get foo.variant-xxxx
created in a merge. If a second merge conflict occurs on that new file,
it was not falling back to putting in the whole key (which should stop
the merge conflicts happening for good, but is ugly).
|
| | |
|
| | |
|
| |
|
|
|
| |
It may be that the directory we need to make a symlink in, to resolve the
merge, doesn't exist locally.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
content settings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
catching exceptions.
As seen in this bug report, the lifted exception handling using the StateT
monad throws away state changes when an action throws an exception.
http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/
.. Which can result in cached values being redundantly calculated, or other
possibly worse bugs when the annex state gets out of sync with reality.
This switches from a StateT AnnexState to a ReaderT (MVar AnnexState).
All changes to the state go via the MVar. So when an Annex action is
running inside an exception handler, and it makes some changes, they
immediately go into affect in the MVar. If it then throws an exception
(or even crashes its thread!), the state changes are still in effect.
The MonadCatchIO-transformers change is actually only incidental.
I could have kept on using lifted-base for the exception handling.
However, I'd have needed to write a new instance of MonadBaseControl
for the new monad.. and I didn't write the old instance.. I begged Bas
and he kindly sent it to me. Happily, MonadCatchIO-transformers is
able to derive a MonadCatchIO instance for my monad.
This is a deep level change. It passes the test suite! What could it break?
Well.. The most likely breakage would be to code that runs an Annex action
in an exception handler, and *wants* state changes to be thrown away.
Perhaps the state changes leaves the state inconsistent, or wrong. Since
there are relatively few places in git-annex that catch exceptions in the
Annex monad, and the AnnexState is generally just used to cache calculated
data, this is unlikely to be a problem.
Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit
redundant. It's now entirely possible to run concurrent Annex actions in
different threads, all sharing access to the same state! The ThreadedMonad
just adds some extra work on top of that, with its own MVar, and avoids
such actions possibly stepping on one-another's toes. I have not gotten
rid of it, but might try that later. Being able to run concurrent Annex
actions would simplify parts of the Assistant code.
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a bug with git annex add in direct mode. If some files already
existed in the tree pointing at the same key as a file that was just added,
and their content was not present, add neglected to copy the content to
those files.
I also changed the behavior of moveAnnex slightly: When content is moved
into the annex in direct mode, it does not overwrite any content already
present in direct mode files. That content may be modified after all.
|
| |\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Annex/Environment.hs
Build/Configure.hs
Git/Construct.hs
Utility/FileMode.hs
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
On POSIX, this just calls changeWorkingDirectory.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
That's needed in files used to build the configure program.
For the other files, I'm keeping my __WINDOWS__ define, as I find that much easier to type.
I may search and replace it to use the mingw32_HOST_OS thing later.
|
| |/ |
|
| |
|
|
| |
from some Android devices may have very broken permissions as received.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
A content directory can be frozen in direct mode. One way this can happen
is if the content is transferred before direct mode has a mapping for it,
so it's stored in the content directory.
So, we need to thaw the content directory before doing things with it.
|
| |
|
|
| |
used. The initremote command now is used only to create new special remotes.
|
| |
|
|
| |
a higher trust level.
|
| | |
|
| |
|
|
|
|
| |
Due to add using withFilesMaybeModified, it will get files that have been
deleted but are still in the index. So catch the IO error that results when
trying to stat such a file.
|
| |
|
|
|
|
|
|
| |
There may be already staged changes from a prior `git annex add`,
so always commit.
Also, suppressed the commit output, since it contains noise due to
typechanged files in direct mode.
|
| | |
|
| |
|
|
|
| |
I think I've been looking for that function for some time.
Ie, I remember wanting to collapse Just Nothing to Nothing.
|
| | |
|
| |
|
|
| |
watch daemon is running.
|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
This is so git remotes on servers without git-annex installed can be used
to keep clients' git repos in sync.
This is a behavior change, but since annex-sync can be set to disable
syncing with a remote, I think it's acceptable.
|
| | |
|
| | |
|
Joey Hess
Joey Hess
Bruno Bigras