| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
* status: Fix --json mode (only the repository lists are currently
displayed)
* status: --fast is back
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
separately.
|
| | |
|
| |
|
|
| |
description specified, don't delete the old description.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoids doing auto-merging in commands that don't need fully current
information from the git-annex branch. In particular, git annex add no
longer needs to auto-merge. Affected commands: Anything that doesn't
look up data from the branch, but does write a change to it.
It might seem counterintuitive that we can change a value without first
making sure we have the current value. This optimisation works because
these two sequences are equivilant:
1. pull from remote
2. union merge
3. read file from branch
4. modify file and write to branch
vs.
1. read file from branch
2. modify file and write to branch
3. pull from remote
4. union merge
After either sequence, the git-annex branch contains the same logical content
for the modified file. (Possibly with lines in a different order or
additional old lines of course).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
More accurately, it was supported already when map uses git-annex-shell,
but not when it does not.
Note that the user name cannot be shell escaped using git-annex's current
approach for shell escaping. I tried and some shells like dash cannot
cd ~'joey'. Rest of directory is still shell escaped, not for security but
in case a directory has a space or other weird character.
|
| |
|
|
| |
3.20111105, whenever the uuid.log is changed (ie, by init or describe).
|
| | |
|
| |
|
|
|
| |
Mostly only refactoring, but this does remove one redundant stat of the
symlink by copy.
|
| | |
|
| |
|
|
|
|
|
| |
files that are already present.
This can be a significant speedup when running in large trees that are
only missing a few files; it makes copy --from just as fast as get.
|
| | |
|
| | |
|
| |
|
|
|
| |
My testing involved widening the race by adding sleeps, and making sure
something sane happens in each case.
|
| | |
|
| | |
|
| |
|
|
|
| |
I've tested that this solves the cyclic drop problem.
Have not looked at cyclic move, etc.
|
| | |
|
| |
|
|
|
| |
This is needed for drop --from and move --from to check the lock,
as they do not use git-annex-shell inannex.
|
| |
|
|
|
|
|
|
| |
git-annex-shell inannex now returns always 0, 1, or 100 (the last when
it's unclear if content is currently in the index due to it currently being
moved or dropped).
(Actual locking code still not yet written.)
|
| |
|
|
|
| |
This is more safe than System.Cmd.Utils.safeSystem, since it does not throw
an error on nonzero exit status.
|
| |
|
|
|
|
|
| |
The lock will only persist during the perform stage, so the content must
be removed from the annex then, rather than in the cleanup stage.
(No lock is actually taken yet.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
Joey Hess
http://cgray.myopenid.com/
http://joey.kitenet.net/
http://www.joachim-breitner.de/