| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In direct mode, it's best to whenever possible not move direct mode files
out of the way, and so I made unannex avoid touching the direct mode file at
all.
That actually turns out to be easy, because in direct mode, unlike indirect
mode, the pre-commit hook won't get confused if the unannexed file later
gets added back by git add. So there's no need to commit the unannex right
away; it can be staged for the user to commit later. This also means that
unannex in direct mode is a lot faster than in indirect mode!
Another subtle bit is the bookkeeping that is done when unannexing a direct
mode file. The inode cache needs to be removed so that when uninit runs
getKeysPresent, it doesn't see the cache and think the key is still
present and crash when it's not.
This commit is sponsored by Douglas Butts. Thanks!
|
| |
|
|
| |
the work tree
|
| |
|
|
| |
that old versions of files and deleted files are not deleted. Print a message with some suggested actions.
|
| | |
|
| |
|
|
| |
not correspond to any unused key.
|
| |
|
|
| |
the urls's path.
|
| | |
|
| |
|
|
| |
useful to put in a post-receive hook to make a repository automatically update its working copy when git annex sync or the assistant sync with it.
|
| |
|
|
| |
last run of git annex unused. Supported by fsck, get, move, copy.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
A common failure mode for direct mode has been for files to end up still
stored in indirect mode. While I hope that doesn't happen anymore, fsck
should deal with it.
|
| |
|
|
| |
On old systems, it may need to be run as root.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It's causing some problem on windows, see
http://git-annex.branchable.com/bugs/windows_port_-_repo_can__39__t_pull_newly_added_files_/#comment-45df9748bba687d95e3c96b3877ea925
And only affected WORM backend, and for one release well over a year ago,
so could well be bitrotted.
|
| |
|
|
|
| |
This is because people continually whine about it. Seemingly not aware
that data generally cannot be deleted from git anyway.
|
| |
|
|
| |
branch on such a remote, instead of to synced/master. This makes it easier to clone from a bare git remote that has been populated with git annex sync or by the assistant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
adding them.
This write permission frobbing is very appropriate in indirect mode,
since annexed objects are stored as immutably as can be managed. But not
in direct mode, where files should be able to be modified at any time.
There are already sufficient guards that there's no need to prevent a file
being written to while it's being ingested, in direct mode. The inode cache
will detect (most) types of modifications, and the add will fail. Then a
re-add should be done. The assistant should get another inotify change
event, and automatically add the new version of the file.
|
| |
|
|
| |
when a new repo is made.
|
| |
|
|
| |
do not support hard links, but do support symlinks and other POSIX filesystem features.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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
|
| | | |
|
Joey Hess