| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
Still a couple of places that use git config ad-hoc, but this is most of it
done.
|
| |
|
|
|
|
|
|
|
|
|
| |
Now there's a Config type, that's extracted from the git config at startup.
Note that laziness means that individual config values are only looked up
and parsed on demand, and so we get implicit memoization for all of them.
So this is not only prettier and more type safe, it optimises several
places that didn't have explicit memoization before. As well as getting rid
of the ugly explicit memoization code.
Not yet done for annex.<remote>.* configuration settings.
|
| | |
|
| | |
|
| |
|
|
|
| |
Increase queue size for update-index actions, because otherwise they'll
never be flushed.
|
| |
|
|
|
| |
May not work. Certianly needs to flush the queue from time to time
when only symlink changes are being made.
|
| |
|
|
|
|
| |
While I was in there, I noticed and fixed a bug in the queue size
calculations. It was never encountered only because Queue.add was
only ever run with 1 file in the list.
|
| |
|
|
|
|
|
|
| |
This allows the queue to be used in a single process for multiple possibly
conflicting commands, like add and rm, without running them out of order.
This assumes that running the same git subcommand with different parameters
cannot itself conflict.
|
| |
|
|
|
|
|
| |
annex.ssh-options, annex.rsync-options, annex.bup-split-options.
And adjust types to avoid the bugs that broke several config settings
recently. Now "annex." prefixing is enforced at the type level.
|
| |
|
|
|
|
|
|
| |
A bit tricky to avoid printing it twice in a row when there are queued git
commands to run and journal to stage.
Added a generic way to run an action that may output multiple side
messages, with only the first displayed.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
useful when adding hundreds of thousands of files on a system with plenty
of memory.
git add gets quite slow in such a large repository, so if the system has
more than the ~32 mb of memory the queue can use by default, it's a useful
optimisation to increase the queue size, in order to decrease the number
of times git add is run.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Many functions took the repo as their first parameter. Changing it
consistently to be the last parameter allows doing some useful things with
currying, that reduce boilerplate.
In particular, g <- gitRepo is almost never needed now, instead
use inRepo to run an IO action in the repo, and fromRepo to get
a value from the repo.
This also provides more opportunities to use monadic and applicative
combinators.
|
| | |
|
| |
|
Joey Hess