| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
| |
Need to make `git annex help command` show the options for that command.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rsync
When rsyncProgress pipes rsync's stdout, this turns out to cause a ssh
process started by rsync to be left behind as a zombie. I don't know why,
but my recent zombie reaping cleanup was correct, it's just that this other
zombie, that's not directly started by git-annex, was no longer reaped
due to changes in the cleanup. Make rsyncProgress reap the zombie started
by rsync, as a workaround.
FWIW, the process tree looks like this. It seems like the rsync child
is for some reason starting but not waiting on this extra ssh process.
Ssh connection caching may be involved -- disabling it seemed to change
the shape of the tree, but did not eliminate the zombie.
9378 pts/14 S+ 0:00 | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ...
9379 pts/14 S+ 0:00 | | \_ ssh ...
9380 pts/14 S+ 0:00 | | \_ rsync -p --progress --inplace -4 -e 'ssh' '-S' ...
9381 pts/14 Z+ 0:00 | \_ [ssh] <defunct>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This seems to fix a problem I've recently seen where ctrl-c during rsync
leads to `git annex get` moving on to the next thing rather than exiting.
Seems likely that started happening with the switch to System.Process
(d1da9cf221aeea5c7ac8a313a18b559791a04f12), as the old code took care
to install a default SIGINT handler.
Note that since the bug was only occurring sometimes, I am not 100% sure
I've squashed it, although I seem to have.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
git-annex (but not git-annex-shell) supports the git help.autocorrect
configuration setting, doing fuzzy matching using the restricted
Damerau-Levenshtein edit distance, just as git does. This adds a build
dependency on the haskell edit-distance library.
|
|
|
|
|
|
|
|
| |
Added Annex.cleanup, which is a general purpose interface for adding
actions to run at the end.
Remotes with the old git-annex-shell will commit every time, and have no
commit command, so hide stderr when running the commit command.
|
|
|
|
|
|
|
| |
This is the last memory leak that prevents git-annex from running
in constant space, as far as I can see. I can now run git annex find
dummied up to repeatedly find the same file over and over, on millions
olf files, and memory stays entirely constant.
|
|
|
|
| |
Avoids ugly (and test suite failing) hack in Command.Version
|
|
|
|
|
|
| |
When converting to the strict state monad, I missed this place where
thunks to the state could be built up, possibly. This seems to make
it run in some percentage less memory.
|
|
|
|
|
|
| |
ghc 7.4 comaplains about use of System.IO.Error to catch exceptions.
Ok, use Control.Exception, with variants specialized to only catch IO
exceptions.
|
|
|
|
|
|
|
|
|
| |
Done by adding a oneshot mode, in which location log changes are written to
the journal, but not committed. Taking advantage of git-annex's existing
ability to recover in this situation.
This is used by git-annex-shell and other places where changes are made to
a remote's location log.
|
|
|
|
|
|
|
|
|
|
|
| |
Ssh connection caching is now enabled automatically by git-annex. Only one
ssh connection is made to each host per git-annex run, which can speed some
things up a lot, as well as avoiding repeated password prompts. Concurrent
git-annex processes also share ssh connections. Cached ssh connections are
shut down when git-annex exits.
Note: The rsync special remote does not yet participate in the ssh
connection caching.
|
| |
|
|
|
|
|
|
| |
Finally commands can define their own options.
Moved --format and --print0 to be options only of find.
|
| |
|
|
|
|
|
| |
Left a few Prelude.head's in where it was checked not null and too hard to
remove, etc.
|
| |
|
| |
|
|
|
|
|
|
|
| |
message, and "git annex version" even works.
Things that sound simple, but are made hard by the Annex monad being built
with the assumption that there will always be a git repo.
|
| |
|
| |
|
|
|
|
| |
No code changes.
|
|
|
|
|
|
|
|
|
| |
This new approach allows filtering out checks from the default set that are
not appropriate for a command, rather than having to list every check
that is appropriate. It also reduces some boilerplate.
Haskell does not define Eq for functions, so I had to go a long way around
with each check having a unique id. Meh.
|
| |
|
| |
|
| |
|
|
|
|
| |
no code changes
|
|
|
|
|
|
| |
Actually, let's do a targeted fix of the actual forkProcess that was not
waited on. The global reap is moved back to the end, after the long-running
git processes actually exit.
|
|
|
|
|
| |
Specifically, when using gpg, a zombie is forked for each file, so waiting
until shutdown to reap won't do.
|
| |
|
|
|
|
| |
Avoid running external command if annex.version is set.
|
|
|
|
| |
This auto-generates a uuid if the local repo does not already have one.
|
|
|
|
|
|
|
| |
when a git repository is first being created. Clones will automatically
notice that git-annex is in use and automatically perform a basic
initalization. It's still recommended to run "git annex init" in any
clones, to describe them.
|
|
|
|
| |
Did all sources except Remotes/* and Command/*
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only remaining vestiage of backends is different types of keys. These
are still called "backends", mostly to avoid needing to change user interface
and configuration. But everything to do with storing keys in different
backends was gone; instead different types of remotes are used.
In the refactoring, lots of code was moved out of odd corners like
Backend.File, to closer to where it's used, like Command.Drop and
Command.Fsck. Quite a lot of dead code was removed. Several data structures
became simpler, which may result in better runtime efficiency. There should
be no user-visible changes.
|
| |
|
|
|
|
| |
It was always imported qualified as Git anyway
|
|
|
|
|
|
|
| |
Otherwise, the location log changes are only staged in its index,
and this can confuse matters if pulling or cloning from the remote.
The test suite was failing because this wasn't done.
|
|
|
|
| |
.. and I think that's everything that will use the branch
|
| |
|
| |
|
|
|
|
|
|
|
| |
Since the queue is flushed in between subcommand actions being run,
there should be no issues with actions that expect to queue up some stuff
and have it run after they do other stuff. So I didn't have to audit for
such assumptions.
|
|
|
|
|
| |
There are two types of commands; those that access the repository and those
that don't. Sorted.
|